[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys
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.
Main Index |
Thread Index |