| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Before we were only calling uao_dropswap() if there was a page, maning
that if the buffer was swapped out then we would leak the slot.
Quite rare because only pipebuffers should swap from the kernel object,
but i've seen panics that implied this had happened (alpha.p for example).
ok thib@ after a lot of discussion and checking the semantics.
|
|
when he copied this code from uvm_km_putpage() into km_free().
Found independently by ariane@; ok deraadt@
|
|
ok deraadt@, miod@
|
|
|
|
The problems during the hackathon were not caused by this (most likely).
prodded by deraadt@ and beck@
|
|
|
|
(uvm_atopg) and use it in uvm_km_doputpage to replace some handrolled
code. Shrinks the kernel a trivial amount.
ok beck@ and miod@ (who suggested i name it uvm_atopg not uvm_atop)
|
|
ok matthew@ tedu@, also eyeballed by at least krw@ oga@ kettenis@ jsg@
|
|
and we aren't sure what's causing them.
shouted oks by many before I even built a kernel with the diff.
|
|
- Use km_alloc for all backend allocations in pools.
- Use km_alloc for the emergmency kentry allocations in uvm_mapent_alloc
- Garbage collect uvm_km_getpage, uvm_km_getpage_pla and uvm_km_putpage
ariane@ ok
|
|
- Change a few KASSERT(0) into proper panics.
- Match the new behavior of single page freeing.
- kremove pages and then free them, it's safer.
thib@ ok
|
|
|
|
|
|
- Clarify a comment.
- Change all the flags to chars from ints to make the structs smaller.
|
|
We've reached the point where we have a dozen allocators that all do more
or less the same thing, but slightly different, with slightly different
semantics, slightly different default behaviors and default behaviors that
most callers don't expect or want. A random sample on the last general
hackathon showed that no one could explain what all the different allocators
did. And every time someone needed to do something slightly different a
new allocator was written.
Unify everything. One single function to allocate multiples of PAGE_SIZE
kernel memory. Four arguments: size, how va is allocated, how pa is allocated
and misc parameters. Same parameters are passed to the free function so that
we don't need to guess what's going on.
Functions are currently unused, we'll do one thing at a time to avoid a
giant commit.
looked at by lots of people, deraadt@ and beck@ are yelling at me to commit.
|
|
ok art@, oga@
|
|
changes it was returing a constant 0, changing to cope
with those changes makes less sense then just removing
as it provides the user with no usefull information.
sthen@ grepped the port's tree for me and found not hits,
thanks!
OK deraadt@, matthew@
|
|
go back to something more like the previous design, and have the thread do
the heavy lifting. solves vmmaplk panics.
ok deraadt oga thib
[and even simple diffs are hard to get perfect. help from mdempsky and deraadt]
|
|
enough.
ok tedu@, art@
|
|
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
|
|
as calls to uvm_km_free_wakup can end up in uvm_mapent_alloc which tries
to grab this mutex.
ok tedu@
|
|
ok tedu@, beck@, oga@
|
|
that md code can peek at it, and update m68k !__HAVE_PMAP_DIRECT setup code
to the recent uvm_km changes.
ok thib@
|
|
recursion in pmap_enter as seen on zaurus.
ok art@
also, release a the uvm_km_page.mtx before calling uvm_km_kmemalloc as we
can sleep there.
ok oga@
|
|
which contains the constraints for DMA/memory allocation for each
architecture, and dma_constraints which contains the range of addresses
that are dma accessable by the system.
This is based on ariane@'s physcontig diff, with lots of bugfixes and
additions the following additions by my self:
Introduce a new function pool_set_constraints() which sets the address
range for which we allocate pages for the pool from, this is now used
for the mbuf/mbuf cluster pools to keep them dma accessible.
The !direct archs no longer stuff pages into the kernel object in
uvm_km_getpage_pla but rather do a pmap_extract() in uvm_km_putpages.
Tested heavily by my self on i386, amd64 and sparc64. Some tests on
alpha and SGI.
"commit it" beck, art, oga, deraadt
"i like the diff" deraadt
|
|
for use by the uvm pseg code. this is the path of least resistance until
we sort out how many of these functions we really need. problem found by mikeb
ok kettenis oga
|
|
whether removing holes or parts of them is allowed or not.
Only allow hole removal in uvmspace_free(), when tearing the vmspace down.
ok art@
|
|
This has has been tested very very thoroughly on all archs we have
excepting 88k and 68k. Please see cvs log for the individual commit
messages.
ok beck@, thib@
|
|
More backouts in line with previous ones, this appears to bring us back to a
stable condition.
A machine forced to 64mb of ram cycled 10GB through swap with this diff
and is still running as I type this. Other tests by ariane@ and thib@
also seem to show that it's alright.
ok deraadt@, thib@, ariane@
|
|
This is for the same reason as the earlier backouts, to avoid the bug
either added or exposed sometime around c2k9. This *should* be the last
one.
prompted by deraadt@
ok ariane@
|
|
uvm_km deals with kernel memory which is either part of one of the
kernel maps, or the main kernel object (a uao). If on km_pgremove we hit
a busy page, just sleep on it, if so there's some async io (and that is
unlikely). we can remove the check for uvm_km_alloc1() for a released page
since now we will never end up with a removed but released page in the kernel
map (due to the other chunk and the last diff).
ok ariane@. Diff survived several make builds, on amd64 and sparc64,
also forced paging with ariane's evil program.
|
|
of uvm_km_pages.
ok deraadt@ tedu@
|
|
now and valid for __HAVE_PMAP_DIRECT archs only, though implements
both code paths.
Put it's code directly into the uvm_km_getpage for PMAP_DIRECT archs.
No functional change.
ok tedu, art
|
|
add a new arg to the backend so it can tell pool to slow down. when we get
this flag, yield *after* putting the page in the pool's free list. whatever
we do, don't let the thread sleep.
this makes things better by still letting the thread run when a huge pf
request comes in, but without artificially increasing pressure on the backend
by eating pages without feeding them forward.
ok deraadt
|
|
example an ioctl that loads bazillions of entries into a pf table) it
would exhaust the pool of free pages and not let uvm_km_thread catch
up until the pool was actually empty. This could be bad for non-sleeping
allocators since they can't wait for the memory while the big hog
can.
Instead of letting the syscall exhaust the pool, detect when we fall below
the low watermark, wake the thread, sleep once and let the thread
catch up. This paces the huge consumer so that the more critical consumers
never find an exhausted pool of pages.
"seems reasonable" kettenis@
|
|
|
|
|
|
when we hit swap before actually fully populating the buffer cache which
would lead to deadlocks.
From pedro, tested by many, deraadt@ ok
|
|
is aligned just fine and in case we allocate the last piece of the
address space we don't want wrap-around to cause us to fail.
pointed out by and ok miod@
|
|
uvm_km_kmemalloc.
"should probbaly go in" millert@, "I think it should too" deraadt@
|
|
miod@ ok
|
|
miod@ ok
|
|
miod@ ok
|
|
to separate locking, on most modern machines this is not enough
since operations on short types touch other short types that share the
same word in memory.
Merge pg_flags and pqflags again and now use atomic operations to change
the flags. Also bump wire_count to an int and pg_version might go
int as well, just for alignment.
tested by many, many. ok 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
|
|
to "pg_flags" and "pg_version", so that they are a bit easier to work with.
Whoever uses generic names like this for a popular struct obviously doesn't
read much code.
Most architectures compile and there are no functionality changes.
deraadt@ ok ("if something fails to compile, we fix that by hand")
|
|
eyeballed by miod@ and pedro@
|
|
|
|
pass zero; this will be used shortly. From art@
|
