[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1001201241540.6440@chino.kir.corp.google.com>
Date: Wed, 20 Jan 2010 12:48:05 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Mel Gorman <mel@....ul.ie>
cc: Andrea Arcangeli <aarcange@...hat.com>,
Christoph Lameter <cl@...ux-foundation.org>,
Adam Litke <agl@...ibm.com>, Avi Kivity <avi@...hat.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 5/7] Add /proc trigger for memory compaction
On Wed, 20 Jan 2010, Mel Gorman wrote:
> > With Lee's work on mempolicy-constrained hugepage allocations, there is a
> > use-case for this explicit trigger to be exported via sysfs in the
> > longterm:
>
> True, although the per-node structures are only available on NUMA making
> it necessary to have two interfaces. The per-node one is handy enough
> because it would be just
>
> /sys/devices/system/node/nodeX/compact_node
> When written to, this node is compacted by the writing process
>
> But there does not appear to be a "good" way of having a non-NUMA
> interface. /sys/devices/system/node does not exist .... Does anyone
> remember why !NUMA does not have a /sys/devices/system/node/node0? Is
> there a good reason or was there just no point?
>
There doesn't seem to be a usecase for a fake node0 sysfs entry since it
would be a duplication of procfs.
I think it would be best to create a global /proc/sys/vm/compact trigger
that would walk all "compactable" zones system-wide and then a per-node
/sys/devices/system/node/nodeX/compact trigger for that particular node,
both with permissions 0200.
It would be helpful to be able to determine what is "compactable" at the
same time by adding both global and per-node "compact_order" tunables that
would default to HUGETLB_PAGE_ORDER. Then, the corresponding "compact"
trigger would only do work if fill_contig_page_info() shows
!free_blocks_suitable for either all zones (global trigger) or each zone
in the node's zonelist (per-node trigger).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists