#
ffff71aa |
| 14-Jan-2025 |
mvs <mvs@openbsd.org> |
Unlock sysctl_malloc().
Move `buckstring' and `memall' strings initialization to the end of kmeminit() to make them immutable. The rest of sysctl_malloc() accessed data is already mp-safe.
ok claud
Unlock sysctl_malloc().
Move `buckstring' and `memall' strings initialization to the end of kmeminit() to make them immutable. The rest of sysctl_malloc() accessed data is already mp-safe.
ok claudio
show more ...
|
#
da5607f6 |
| 26-Jun-2024 |
jsg <jsg@openbsd.org> |
return type on a dedicated line when declaring functions ok mglocker@
|
#
d6514e0f |
| 14-Dec-2023 |
claudio <claudio@openbsd.org> |
Workaround for broken clang which has a broken -fno-zero-initialized-in-bss implementation.
Set nkmempages to -1 by default instead of 0 so that the value ends up in the data section. This way confi
Workaround for broken clang which has a broken -fno-zero-initialized-in-bss implementation.
Set nkmempages to -1 by default instead of 0 so that the value ends up in the data section. This way config(8) is able to alter the value as promised.
See also: https://github.com/llvm/llvm-project/issues/74632 OK miod@
show more ...
|
#
ca803f33 |
| 14-Dec-2023 |
claudio <claudio@openbsd.org> |
Bring default logic to set nkmempages into the 21st century.
The new logic is: Up to 1G physmem use physical memory / 4, above 1G add an extra 16MB per 1G of memory.
Clamp it down depending on avai
Bring default logic to set nkmempages into the 21st century.
The new logic is: Up to 1G physmem use physical memory / 4, above 1G add an extra 16MB per 1G of memory.
Clamp it down depending on available kernel virtual address space - up and including 512M -> 64MB (macppc, arm, sh) - between 512M and 1024M -> 128MB (hppa, i386, mips, luna88k) - over 1024M clamping to VM_KERNEL_SPACE_SIZE / 4
The result is much more malloc(9) space on 64bit archs with lots of memory and large kva space. Note: amd64 only has 4G of kva and therefor nkmempages is limited to 262144
As a side-effect NKMEMPAGES_MAX and nkmempages_max are no longer used. Tested and OK miod@
show more ...
|
#
f4810b03 |
| 29-Nov-2023 |
claudio <claudio@openbsd.org> |
Cleanup kmeminit_nkmempages().
NKMEMPAGES_MIN was removed long time ago in all archs so there is no need to keep it. Also initalize nkmempages_max at compile time since sparc (with variable page siz
Cleanup kmeminit_nkmempages().
NKMEMPAGES_MIN was removed long time ago in all archs so there is no need to keep it. Also initalize nkmempages_max at compile time since sparc (with variable page size) is long gone as well. No objection from miod@
show more ...
|
#
0d280c5f |
| 14-Aug-2022 |
jsg <jsg@openbsd.org> |
remove unneeded includes in sys/kern ok mpi@ miod@
|
#
feb3ff6b |
| 04-May-2022 |
bluhm <bluhm@openbsd.org> |
Introduce mutex for ratecheck(9) and ppsratecheck(9). A global mutex with spl high for all function calls is used for now. It protects the lasttime and curpps parameter. This solution is MP safe f
Introduce mutex for ratecheck(9) and ppsratecheck(9). A global mutex with spl high for all function calls is used for now. It protects the lasttime and curpps parameter. This solution is MP safe for the usual use case, allows progress, and can be optimized later. Remove a useless #if 1 while there. OK claudio@
show more ...
|
#
4123b6a7 |
| 16-May-2021 |
deraadt <deraadt@openbsd.org> |
panic does not require a \n at the end. When one is provided, it looks wrong.
|
#
388a5417 |
| 21-Apr-2021 |
mpi <mpi@openbsd.org> |
Convert remaining uvm_km_zalloc(9) to km_alloc(9).
Tested by bluhm@, jj@, kettenis@ and Scott Bennett.
ok kettenis@
|
#
e587a465 |
| 23-Feb-2021 |
jsg <jsg@openbsd.org> |
remove unused malloc_roundup()
|
#
48eb9f4d |
| 31-Dec-2020 |
claudio <claudio@openbsd.org> |
Add trace points for malloc(9) and free(9). This makes them traceable via dt(4) and btrace(8). OK mpi@ millert@
|
#
957017e2 |
| 14-Oct-2020 |
deraadt <deraadt@openbsd.org> |
delete strange historical FFS_SOFTUPDATES ifdef... ok millert
|
#
babb761d |
| 19-Dec-2019 |
mpi <mpi@openbsd.org> |
Convert infinite sleeps to {m,t}sleep_nsec(9).
ok visa@
|
#
610978bc |
| 28-Nov-2019 |
guenther <guenther@openbsd.org> |
Delete km_mapblocks from kmemstats and its always-zero column from the ddb "show malloc" output
ok deraadt@ mpi@
|
#
d3ca6102 |
| 15-May-2019 |
tedu <tedu@openbsd.org> |
rework the zero warning slightly, and more completely disable until we're more ready to deal with the noise.
|
#
2dec572b |
| 09-May-2019 |
tedu <tedu@openbsd.org> |
disable stack printing for now since at least arm64 can't print them reported by kettenis
|
#
5cb55026 |
| 08-May-2019 |
tedu <tedu@openbsd.org> |
print a few warnings when calling free with a zero size. let's see what falls out. ok beck deraadt kettenis mpi
|
#
4120fcf0 |
| 10-Jul-2018 |
bluhm <bluhm@openbsd.org> |
In free(9) call wakeup() after mtx_leave() consistently. OK kettenis@ visa@ mpi@
|
#
5c57e1c5 |
| 09-Jul-2018 |
bluhm <bluhm@openbsd.org> |
Fix trailing whitespaces and too long line.
|
#
21c85adc |
| 09-Jul-2018 |
bluhm <bluhm@openbsd.org> |
Make free(9) MP safe. It was wrong to set ku_indx to 0 after freeing the memory in uvm. Another process could use the false 0 then. To be on the safe side, protect all access to ku_indx and ku_pag
Make free(9) MP safe. It was wrong to set ku_indx to 0 after freeing the memory in uvm. Another process could use the false 0 then. To be on the safe side, protect all access to ku_indx and ku_pagecnt with a mutex. Update ku_indx and ku_pagecnt before calling uvm_km_free(). Update ksp after uvm_km_free() to keep accounting correct. tested by sthen@; OK mpi@ visa@ deraadt@
show more ...
|
#
a97ba27b |
| 18-Jan-2018 |
bluhm <bluhm@openbsd.org> |
While booting it does not make sense to wait for memory, there is no other process which could free it. Better panic in malloc(9) or pool_get(9) instead of sleeping forever. tested by visa@ patrick@
While booting it does not make sense to wait for memory, there is no other process which could free it. Better panic in malloc(9) or pool_get(9) instead of sleeping forever. tested by visa@ patrick@ Jan Klemkow suggested by kettenis@; OK deraadt@
show more ...
|
#
29e47708 |
| 02-Jan-2018 |
guenther <guenther@openbsd.org> |
Fix an off-by-one in the free(9) "passed size was too small" check: if the size passed is exactly half the size of the bucket that the allocation was actually from, then it was incorrect.
problem no
Fix an off-by-one in the free(9) "passed size was too small" check: if the size passed is exactly half the size of the bucket that the allocation was actually from, then it was incorrect.
problem noted by florian@ ok florian@ visa@
show more ...
|
#
4c380d4e |
| 14-Nov-2017 |
dlg <dlg@openbsd.org> |
remove MALLOC_DEBUG
the code has rotted, and obviously hasnt been used for ages. it is also hard to make mpsafe. if we need something like this again it would be better to do it from scratch.
ok te
remove MALLOC_DEBUG
the code has rotted, and obviously hasnt been used for ages. it is also hard to make mpsafe. if we need something like this again it would be better to do it from scratch.
ok tedu@ visa@
show more ...
|
#
7282a73c |
| 10-Jul-2017 |
dlg <dlg@openbsd.org> |
make malloc(9) mpsafe by using a mutex instead of splvm.
this is almost a straightforward change of spl ops with mutex ops, except the accounting has been shuffled around. memory is counted as used
make malloc(9) mpsafe by using a mutex instead of splvm.
this is almost a straightforward change of spl ops with mutex ops, except the accounting has been shuffled around. memory is counted as used before an attempt to allocate it from uvm is made to prevent overcommitting memory. this is modelled on how pools limit allocations.
the uvm bits have been eyeballed by kettenis@ who says they should be safe. visa@ found some nits which have been fixed.
tested by chris@ and amit kulkarni ok kettenis@ visa@ mpi@
show more ...
|
#
1a582ed7 |
| 07-Jun-2017 |
mpi <mpi@openbsd.org> |
Assert that the calling CPU is holding the KERNEL_LOCK() in malloc(9) and free(9).
The exception is at early boot when only one CPU is running since we grab the KERNL_LOCK() relatively late in main(
Assert that the calling CPU is holding the KERNEL_LOCK() in malloc(9) and free(9).
The exception is at early boot when only one CPU is running since we grab the KERNL_LOCK() relatively late in main().
ok kettenis@
show more ...
|