[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys
On Fri, Feb 18, 2011 at 5:57 PM, Matt Thomas <matt%3am-software.com@localhost>
> On Feb 17, 2011, at 11:24 PM, Lars Heidieker wrote:
>> On Thu, Feb 17, 2011 at 8:27 PM, Matt Thomas <matt%netbsd.org@localhost>
>>> 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.
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 ]
Main Index |
Thread Index |