Re: CVS commit: src/sys

[Lars Heidieker <lars.heidieker%googlemail.com@localhost>]

On Fri, Feb 18, 2011 at 5:57 PM, Matt Thomas <matt%3am-software.com@localhost> 
wrote:
>
> 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> 
>> 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 ]