#
1b92846d |
| 20-Aug-2024 |
mvs <mvs@openbsd.org> |
Unlock KERN_MAXFILES.
`maxfiles' is atomically accessed integer which is lockless and read-only accessed in file descriptors layer.
lim_startup() called during kernel bootstrap, no need to atomic_l
Unlock KERN_MAXFILES.
`maxfiles' is atomically accessed integer which is lockless and read-only accessed in file descriptors layer.
lim_startup() called during kernel bootstrap, no need to atomic_load_int() within.
ok mpi
show more ...
|
#
2d79d4b5 |
| 20-Aug-2024 |
mvs <mvs@openbsd.org> |
Unlock KERN_MAXPROC and KERN_MAXTHREAD from `kern_vars'. Both `maxprocess' and `maxthread' are atomically accessed integers.
ok mpi
|
#
5ec8126a |
| 05-May-2024 |
jsg <jsg@openbsd.org> |
remove unneeded includes
|
#
aba40e07 |
| 04-Jul-2023 |
jsg <jsg@openbsd.org> |
Remove mbuf low watermark vars. Unused since uipc_mbuf.c rev 1.244. ok kn@ bluhm@
|
#
d8920042 |
| 03-Mar-2023 |
cheloha <cheloha@openbsd.org> |
initclocks: don't reinitialize ticks, jiffies at runtime
Various drivers use ticks/jiffies before initclocks(). It isn't generally safe to reinitialize them at runtime. Hoist the conditional defin
initclocks: don't reinitialize ticks, jiffies at runtime
Various drivers use ticks/jiffies before initclocks(). It isn't generally safe to reinitialize them at runtime. Hoist the conditional definition of HZ from param.c into sys/kernel.h so we can see it from kern_clock.c and statically initialize ticks/jiffies to the desired offset.
With this change, timeouts scheduled before initclocks() do not all fire immediately during the first softclock().
With input from kettenis@.
Link: https://marc.info/?l=openbsd-tech&m=167753870803378&w=2
show more ...
|
#
8458ad5d |
| 13-Apr-2022 |
sthen <sthen@openbsd.org> |
Use a simpler "formula" to decide a default kern.maxthread value; just 2*NPROCESS rather than NPROCESS+8*MAXUSERS. Results in a slightly higher maxthread value - the previous value was fairly likely
Use a simpler "formula" to decide a default kern.maxthread value; just 2*NPROCESS rather than NPROCESS+8*MAXUSERS. Results in a slightly higher maxthread value - the previous value was fairly likely to be exceeded on a system running a couple of heavily threaded processes.
> previous new > MAXUSERS NPROCESS maxthread (2*NPROCESS) > 80 1310 1950 2620 > 64 1054 1566 2108 > 32 542 798 1084
ok kettenis@
show more ...
|
#
9589ba9d |
| 13-Jan-2021 |
cheloha <cheloha@openbsd.org> |
kernel, sysctl(8): remove dead variable: tickadj
The global "tickadj" variable is a remnant of the old NTP adjustment code we used in the kernel before the current timecounter subsystem was imported
kernel, sysctl(8): remove dead variable: tickadj
The global "tickadj" variable is a remnant of the old NTP adjustment code we used in the kernel before the current timecounter subsystem was imported from FreeBSD circa 2004 or 2005.
Fifteen years hence it is completely vestigial and we can remove it. We probably should have removed it long ago but I guess it slipped through the cracks. FreeBSD removed it in 2002:
https://cgit.freebsd.org/src/commit/?id=e1d970f1811e5e1e9c912c032acdcec6521b2a6d
NetBSD and DragonflyBSD can probably remove it, too.
We export tickadj via the kern.clockrate sysctl(2), so update sysctl.2 and sysctl(8) accordingly. Hypothetically this change could break someone's sysctl(8) parsing script. I don't think that's very likely.
ok mvs@
show more ...
|
#
fc987604 |
| 07-Sep-2019 |
cheloha <cheloha@openbsd.org> |
Remove tz, the kernel timezone.
After removing timezone support from date(1), msdosfs, gettimeofday(2), settimeofday(2), boot_config(8), config(8), and introducing kern.utc_offset sysctl(2) to repla
Remove tz, the kernel timezone.
After removing timezone support from date(1), msdosfs, gettimeofday(2), settimeofday(2), boot_config(8), config(8), and introducing kern.utc_offset sysctl(2) to replace the DST/TIMEZONE options(4) to support running the RTC at an offset from UTC, the kernel timezone is unused and we can delete it.
With this commit the kernel timezone now appears to be extinct in upstream BSD, though it does survive in XNU:
https://github.com/opensource-apple/xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/bsd/conf/param.c#L83
Prompted by tedu@ some time back, and inspired by NetBSD and FreeBSD's work in this area.
ok deraadt@
show more ...
|
#
db1dd8d3 |
| 21-Aug-2019 |
cheloha <cheloha@openbsd.org> |
sysctl(2): add kern.utc_offset: successor to the DST/TIMEZONE options(4)
The DST and TIMEZONE options(4) are incompatible with KARL, so we need some other way to compensate for an RTC running with a
sysctl(2): add kern.utc_offset: successor to the DST/TIMEZONE options(4)
The DST and TIMEZONE options(4) are incompatible with KARL, so we need some other way to compensate for an RTC running with a known offset.
Enter kern.utc_offset, an offset in minutes East of UTC. TIMEZONE has always been minutes West, but this is inconsistent with how everyone else talks about timezones, hence the flip.
TIMEZONE has the advantage of being compiled into the binary. Our new sysctl(2) has no such luck, so it needs to be set as early as possible in boot, from sysctl.conf(5), so we can correct the kernel clock from the RTC's local time to UTC before daemons like ntpd(8) and cron(8) start. To encourage this, kern.utc_offset is made immutable after the securelevel(7) is raised to 1.
Prompted by yasuoka@. Discussed with deraadt@, kettenis@, yasuoka@. Additional testing by yasuoka@.
ok deraadt@, yasuoka@
show more ...
|
#
fcfbe7d9 |
| 02-Aug-2019 |
cheloha <cheloha@openbsd.org> |
per-process itimers: itimerval -> itimerspec
Loongson runs at 128hz. 128 doesn't divide evenly into a million, but it does divide evenly into a billion. So if we do the per-process itimer bookkeep
per-process itimers: itimerval -> itimerspec
Loongson runs at 128hz. 128 doesn't divide evenly into a million, but it does divide evenly into a billion. So if we do the per-process itimer bookkeeping with itimerspec structs we can have error-free virtual itimers on loongson just as we do on most other platforms.
This change doesn't fix the virtual itimer error alpha, as 1024 does not divide evenly into a billion. But this doesn't make the situation any worse, either.
ok deraadt@
show more ...
|
#
9392a735 |
| 16-Jul-2019 |
bluhm <bluhm@openbsd.org> |
Prevent integer overflow in kernel and userland when checking mbuf limits. Convert kernel variables and calculations for mbuf memory into long to allow larger values on 64 bit machines. Put a range
Prevent integer overflow in kernel and userland when checking mbuf limits. Convert kernel variables and calculations for mbuf memory into long to allow larger values on 64 bit machines. Put a range check into the kernel sysctl. For the interface itself int is still sufficient. In netstat -m cast all multiplications to unsigned long to hold the product of two unsigned int. input and OK visa@
show more ...
|
#
34349d00 |
| 08-Jul-2019 |
mlarkin <mlarkin@openbsd.org> |
Remove trailing whitespace from a macro
ok deraadt
|
#
05ab60ea |
| 28-Apr-2019 |
deraadt <deraadt@openbsd.org> |
the bufcachepercent=80 experiment has exposed a few problems...
|
#
c866b26a |
| 20-Apr-2019 |
deraadt <deraadt@openbsd.org> |
as discussed with beck, crank dma-range bufcache to a high number (he suggested 90 but I prefer 80). This is so we learn the downside from user reports.
|
#
109396cc |
| 03-Oct-2017 |
deraadt <deraadt@openbsd.org> |
work around config(8) modifying bss, using __attribute__ ((section(".data"))). From yasuoka. I really want this fixed in a different way after release is finished.
|
#
fb661dc7 |
| 06-May-2016 |
kettenis <kettenis@openbsd.org> |
Revert the previous commit. There still are bad interactions between the pagedaemon and the buffer cache.
requested by deraadt@
|
#
241f9807 |
| 18-Apr-2016 |
beck <beck@openbsd.org> |
Bump the default of cachepercent to 90 to see if we can find problems before we try to remove it entirely ok deraadt@
|
#
6dfb9dde |
| 09-Jan-2015 |
tedu <tedu@openbsd.org> |
rename desiredvnodes to initialvnodes. less of a lie. ok beck deraadt
|
#
e6fd2ff8 |
| 10-Apr-2012 |
guenther <guenther@openbsd.org> |
Make the KERN_NPROCS and KERN_MAXPROC sysctl()s and the RLIMIT_NPROC rlimit count processes instead of threads. New sysctl()s KERN_NTHREADS and KERN_MAXTHREAD count and limit threads. The nprocs an
Make the KERN_NPROCS and KERN_MAXPROC sysctl()s and the RLIMIT_NPROC rlimit count processes instead of threads. New sysctl()s KERN_NTHREADS and KERN_MAXTHREAD count and limit threads. The nprocs and maxproc kernel variables are replaced by nprocess, maxprocess, nthreads, and maxthread.
ok tedu@ mikeb@
show more ...
|
#
23c0f0c8 |
| 08-Aug-2011 |
deraadt <deraadt@openbsd.org> |
Ship 5.0 with bufcachepercent=20
|
#
f46f5a90 |
| 05-Jun-2011 |
deraadt <deraadt@openbsd.org> |
Move the bufcachepercent setting code to MI locations -- set it to 42% for now; that is unlikely to hit some of the remaining starvation bugs. Repair the bufpages calculation too; i386 was doing it a
Move the bufcachepercent setting code to MI locations -- set it to 42% for now; that is unlikely to hit some of the remaining starvation bugs. Repair the bufpages calculation too; i386 was doing it ahead of time (incorrectly) and then re-calculating it. ok thib
show more ...
|
#
ce928c9b |
| 08-Dec-2009 |
miod <miod@openbsd.org> |
Remove old SysV SHM size limits global variables, they are no longer needed since blambert@ rewrote the allocation code.
|
#
61499fa0 |
| 09-Aug-2009 |
blambert <blambert@openbsd.org> |
Rototill system V message queues.
No longer allocate a static amount of memory for messages in MD boot path; message queues, message metadata, and message data now all use dynamic memory, which mean
Rototill system V message queues.
No longer allocate a static amount of memory for messages in MD boot path; message queues, message metadata, and message data now all use dynamic memory, which means that runtime sysctls should now be trivial to implement.
Since I'm going to be around all week to fix any breakage, this should probably just go in now.
show more ...
|
#
62feaf57 |
| 20-Mar-2008 |
deraadt <deraadt@openbsd.org> |
we now have a higher count of kernel threads on many machines, so crank the base amount in NPROC to 30; ok miod
|
#
532045ec |
| 02-Nov-2007 |
millert <millert@openbsd.org> |
crank maxfiles; OK deraadt@
|