On Fri, Feb 18, 2011 at 5:57 PM, Matt Thomas <[email protected]> wrote: > > On Feb 17, 2011, at 11:24 PM, Lars Heidieker wrote: > >> On Thu, Feb 17, 2011 at 8:27 PM, Matt Thomas <[email protected]> wrote: >>> Module Name: src >>> Committed By: matt >>> Date: Thu Feb 17 19:27:13 UTC 2011 >>> >>> Modified Files: >>> src/sys/kern: kern_kthread.c >>> src/sys/uvm: uvm_extern.h uvm_glue.c >>> >>> Log Message: >>> Add support for cpu-specific uarea allocation routines. Allows different >>> allocation for user and system lwps. MIPS will use this to map uareas of >>> system lwp used direct-mapped addresses (to reduce the overhead of >>> switching to kernel threads). ibm4xx could use to map uareas via direct >>> mapped addresses and avoid the problem of having the kernel stack not in >>> the TLB. >> >> Hi, I get the idea of this change but not quite complete. >> First I got the a compile error on amd64, thats what made me look at it. >> An ifdef arround the initialization of the uvm_uarea_system_cache is missing. >> What are the cpu_uarea_alloc functions supposed to do, differently >> from the PMAP_MAP_POOLPAGE approach, I guess they are able to alloc >> multiplies of PAGE_SIZE with the correct alignment, if so once they >> are in place the PMAP_MAP_POOLPAGE is not required any more? >> I think MIPS currently uses PMAP_MAP_POOLPAGE. >> And why treat system lwp uareas differently from user ones? >> >> Sorry if I miss something here. > > PMAP_MAP_POOLPAGE can only map a single page. The UAREA on MIPS is 2 > pages so you PMAP_MAP_POOLPAGE can't be used. You need to allocate 2 > physically contiguous pages which the uvm km code can't do. > > The reason for this is for fast softints. Switching to their kernel > stacks and then back to user stack would involve updating the TLB > that maps the kernel stack twice. By keeping those stacks direct > mapped, that double update can be avoided. > > On LP64 kernels, since all memory can be direct mapped, all UAREAs > will be attempted to be mapped physically since that's results in > a small performance boost.
I can see the advantage especially for MIPS with it's alignment constrains in the TLB and utilizing direct mapped segments... But doesn't this mean the page-allocator should have some kind of body-system to deliver physically contiguous pages in general, such a thing would be nice for super-pages as well as the pool-allocators (if they need large the PAGE_SIZE) pages. -- Mystische Erklärungen: Die mystischen Erklärungen gelten für tief; die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind. -- Friedrich Nietzsche [ Die Fröhliche Wissenschaft Buch 3, 126 ]
