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