| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
in MI code; gcc 2.95 does not accept such annotation for function pointer
declarations, only function prototypes.
To be uncommented once gcc 2.95 bites the dust.
|
|
|
|
|
|
| |
function pointer arguments which are {used as,} wrappers around the kernel
printf function.
No functional change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
no oks (it is really a pain to review properly)
extensively tested, I'm confident it'll be stable
'now is the time' from several icb inhabitants
Diff provides:
- ability to specify different allocators for different regions/maps
- a simpler implementation of the current allocator
- currently in compatibility mode: it will generate similar addresses
as the old allocator
|
|
|
|
| |
ok deraadt@
|
|
|
|
| |
outside the tree.
|
|
|
|
|
|
| |
appears to be safe now. If not, we'll know soon where the bugs lie, so
that we can fix them. This diff has been in snapshots for many months.
ok oga miod
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vmmap is designed to perform address space randomized allocations,
without letting fragmentation of the address space go through the roof.
Some highlights:
- kernel address space randomization
- proper implementation of guardpages
- roughly 10% system time reduction during kernel build
Tested by alot of people on tech@ and developers.
Theo's machines are still happy.
|
|
|
|
|
| |
have real values, no 0 values anymore.
ok deraadt kettenis krw matthew oga thib
|
|
|
|
|
|
|
|
|
|
| |
Currently only checks that we're not in an interrupt context, but will
soon check that we're not holding any mutexes either.
Update malloc(9) and pool(9) to use assertwaitok(9) as appropriate.
"i like it" art@, oga@, marco@; "i see no harm" deraadt@; too trivial
for me to bother prying actual oks from people.
|
|
|
|
|
|
| |
so no point in reserving space for kmemstats unless it's enabled.
ok thib@, deraadt@
|
|
|
|
|
|
|
|
|
| |
Use uvm_km_kmemalloc_pla with the dma constraint to allocate kernel stacks.
Yes, that means DMA is possible to kernel stacks, but only until we've fixed
all the scary drivers.
deraadt@ ok
|
|
|
|
|
|
|
| |
Do this by calling uvm_km_kmemalloc_pla with the dma_constraint.
ok art@ (ofcourse, he eats his cereal and okeys everything).
OK beck@, deraadt@
|
|
|
|
|
|
|
|
| |
uvm_map_checkprot() call, if the memory we're about to return has just been
allocated with uvm_km_kmemalloc() instead of coming from the freelist.
No functional change but a very small speedup when the freelist for the given
bucket is empty.
|
|
|
|
|
|
|
|
|
| |
input, in order to pick the appropriate malloc() bucket.
Replace it with an inline function in kern_malloc.c, which will either
do a tightest-but-slower loop (if option SMALL_KERNEL), or a geometric search
equivalent to what the macro does, but producing smaller code (especially on
platforms which can not load large constants in one instruction).
|
|
|
|
|
|
|
| |
value (based on physmem) is below NKMEMPAGES_MIN, we are on a low memory
machine and can not afford more anyway.
ok deraadt@ tedu@
|
|
|
|
|
|
|
|
| |
changes the pressure on the uvm system, uncovering several bugs. Some
of those bugs result in provable deadlocks. We'll have to reconsider
integrating this diff again after fixing those bugs.
ok art@
|
|
|
|
|
|
|
|
| |
instead of M_NOWAIT. Checking for M_NOWAIT made many malloc calls that used
that flag actually wait. This probably explains many if the strange hangs
people have seen recently.
ok miod@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow us to escape the limitations of kmem_map.
At this moment, the per-type limits are still enforced for all sizes,
but we might loosen that limit in the future after some thinking.
Original diff from Mickey in kernel/5761 , I massaged it a little to
obey the per-type limits.
miod@ ok
|
|
|
|
|
|
| |
From NetBSD, kindly pointed out by YAMAMOTO Takashi.
ok miod@
|
|
|
|
| |
help and ok miod@ thib@
|
|
|
|
|
|
|
|
|
|
|
| |
But the reason for this isn't some kind of "we can make it use the
pre-zeroed pages and zero the freelist in the idle loop and OMG I can
has optimisatiuns" which would require tons of infrastructure and make
everything slower.
The reason is that it shrinks other code. And that's good.
dlg@ ok, henning@ ok (before he read the diff)
|
|
|
|
|
|
|
|
| |
version for i386
more architectures and ctob() replacement is being worked on
prodded by and ok miod
|
|
|
|
|
|
| |
Pick reasonble names for the locks involved..
ok tedu@, art@
|
|
|
|
|
|
|
|
| |
and make sure that nothing can ever be mapped at theses addresses.
Only i386 overrides the default for now.
From mickey@, ok art@ miod@
|
|
|
|
|
|
|
|
| |
kmem_object) just so that we can remove them, just use pmap_extract
to get the pages to free and simplify a lot of code to not deal with
the list of intrsafe maps, intrsafe objects, etc.
miod@ ok
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit:
- gdt lock on amd64
- sysctl lock
- malloc sysctl lock
- disk sysctl lock
- swap syscall lock
miod@, pedro@ ok (and "looks good" others@)
|
|
|
|
| |
M_CANFAIL, idea from miod@, okay deraadt@
|
|
|
|
|
|
| |
return NULL instead of panic()'ing.
ok pedro@, deraadt@
|
| |
|
|
|
|
| |
'go for it' deraadt@
|
|
|
|
|
|
| |
of panics and bugfixes. Access curproc directly, do not expect a process
pointer as an argument. Should fix many "process context required" bugs.
Incentive and okay millert@, okay marc@. Various testing, thanks.
|
|
|
|
|
| |
arches; except on sparc where the range is 4-8 for !sun4m and 4-64 for sun4m,
selected at runtime.
|
| |
|
| |
|
|
|
|
| |
from form@pdp-11.org.ru via mpech. ok millert
|
|
|
|
|
| |
less error prone (no wraparound). no real functional change though.
ok markus tdeval
|
|
|
|
| |
takes a void *. convert uiomove to take a void * as well. ok deraadt@
|
| |
|
|
|
|
| |
rescinded 22 July 1999. Proofed by myself and Theo.
|
|
|
|
|
|
|
|
| |
uses it as a hint for where to steal space from the parent map. We've been
passing random stack garbage as that hint for ages. It's a wonder it didn't
break things until we started working on Hammer.
noone objected for at least a week.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
okay art@
|
| |
|
|
|
|
|
|
|
|
|
| |
machines or some configurations or in some phase of the moon (we actually
don't know when or why) files disappeared. Since we've not been able to
track down the problem in two weeks intense debugging and we need -current
to be stable, back out everything to a state it had before UBC.
We apologise for the inconvenience.
|