[Celinux-dev] big physical-continuous memory allocation

Paul Mundt lethal at linux-sh.org
Wed Aug 22 20:31:47 PDT 2007


On Wed, Aug 22, 2007 at 04:18:43PM +0200, Paolo Giarrusso wrote:
> 2007/8/20, Paul Mundt <lethal at linux-sh.org>:
> > It would be interesting to see what could be done with page migration for
> > node-local defrag. While that wouldn't be of much use for a 2MB
> > contiguous block on a loaded node, it could still help for the cases
> > where even 1-order allocations end up being hard to satisfy after being
> > under prolonged pressure.
> >
> > This would also provide a basis for coalescing adjacent page frames in to
> > larger TLBs, with the trade-off being in the background scanning.
> 
> However, IIRC, in most (if not all) approaches, pages to be removed
> were reclaimed, not moved elsewhere; in fact, this can only be done
> with pages representing caches, so that the kernel already knows they
> may be detached. Moving a page containing kernel space data is not
> going to ever work, since you do not know how many pointers to that
> page may have to be fixed up.
> 
Moving kernel pages is not relevant to this discussion, which is
specifically why the topic was page migration, not reclaim. Most of the
kernel mappings are already mapped using large TLBs where it matters, the
more interesting case for embedded is promotion to larger TLBs for
adjacent page frames while sticking with the same base page size (rather
than building up compound pages, huge TLBs, etc.), particularly for
those platforms with tiny software-filled TLBs (or even the silly ones
with so much cache that they exhaust TLB coverage before even making it
to system memory without resorting to an insanely huge PAGE_SIZE).

This and Mel's ZONE_MOVABLE work are complementary in some regards, but
not directly related. They're rather different problem spaces, even if
there is some conceptual overlap. It would also be pointless to attempt
TLB promotion if there were little chance of the system having any more
than a 0-order contiguous page range.


More information about the Celinux-dev mailing list