Age | Commit message (Collapse) | Author |
|
(VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS). This will allow these to no
longer be constants in the future.
ok guenther@
|
|
comment (one is fixed, one is deleted).
ok kettenis beck
|
|
by the caller on architectures that implement them. Make sure that we
physically align memory such that we meet any demands on virtual alignment
in this case. This should reduce the overhead of mapping large pool pages
for pools that request dma'able memory.
ok deraadt@, dlg@
|
|
doesn't have all the values and therefore can't be used everywhere.
ok deraadt@ kettenis@
|
|
eliminating the must-be-kept-in-sync UVM_INH_* macros
ok deraadt@ tedu@
|
|
in there. It explicitly changes the mapping of that memory to RX, but this
only works if the maximum protection of the mapping includes PROT_EXEC.
ok miod@, deraadt@
|
|
mappings via this interface (nothing uses it, in any case)
ok uebayasi tedu
|
|
just the base permission but the maxprot as well.
ok tedu
|
|
that is executable.
ok tedu kettenis guenther
|
|
PROT_NONE, PROT_READ, PROT_WRITE, and PROT_EXEC from mman.h.
PROT_MASK is introduced as the one true way of extracting those bits.
Remove UVM_ADV_* wrapper, using the standard names.
ok doug guenther kettenis
|
|
|
|
ok mpi@ kspillner@
|
|
on the 2nd of February 2011 in NetBSD.
http://marc.info/?l=netbsd-source-changes&m=129658899212732&w=2
http://marc.info/?l=netbsd-source-changes&m=129659095515558&w=2
http://marc.info/?l=netbsd-source-changes&m=129659157916514&w=2
http://marc.info/?l=netbsd-source-changes&m=129665962324372&w=2
http://marc.info/?l=netbsd-source-changes&m=129666033625342&w=2
http://marc.info/?l=netbsd-source-changes&m=129666052825545&w=2
http://marc.info/?l=netbsd-source-changes&m=129666922906480&w=2
http://marc.info/?l=netbsd-source-changes&m=129667725518082&w=2
|
|
was empty then the first page allocation should sleep until it can get one.
ok tedu@
|
|
emphatic ok usual suspects, grudging ok miod
|
|
|
|
|
|
|
|
pages, so fix non-sensical comparison introduced in rev 1.77.
ok miod@, krw@, beck@
|
|
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
|
|
The vm hackers don't use it, don't maintain it and have to look at it all the
time. About time this 800 lines of code hit /dev/null.
``never liked it'' tedu@. ariane@ was very happy when i told her i wrote
this diff.
|
|
It will handle an empty list just fine (there's a small optimisation
possible here to avoid grabbing the fpageqlock if no pages need freeing,
but that is definitely another diff)
ok ariane@
|
|
Requested by dlg@
ok oga@
|
|
outside the tree.
|
|
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
|