Re: CVS commit: src/sys

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Lars Heidieker <lars.heidieker%googlemail.com@localhost> wrote:
> > 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.
> 

There is uvm_pglistalloc() to allocate physically contiguous block.
However, uvm_km(9) is not capable of "customised" allocations, like
having contiguous block and direct map.  Moreover, space for direct
mapping is limited (plus not all architectures support it).

In the longer term - yes, large ("super") pages should be supported,
and perhaps such "customised" allocations with it.  This is quite not
trivial to implement, though.

-- 
Mindaugas