[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <509985DE.8000508@linux.vnet.ibm.com>
Date: Tue, 06 Nov 2012 13:49:18 -0800
From: Dave Hansen <dave@...ux.vnet.ibm.com>
To: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
CC: akpm@...ux-foundation.org, mgorman@...e.de, mjg59@...f.ucam.org,
paulmck@...ux.vnet.ibm.com, maxime.coquelin@...ricsson.com,
loic.pallardy@...ricsson.com, arjan@...ux.intel.com,
kmpark@...radead.org, kamezawa.hiroyu@...fujitsu.com,
lenb@...nel.org, rjw@...k.pl, gargankita@...il.com,
amit.kachhap@...aro.org, svaidy@...ux.vnet.ibm.com,
thomas.abraham@...aro.org, santosh.shilimkar@...com,
linux-pm@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 6/8] mm: Demarcate and maintain pageblocks in region-order
in the zones' freelists
On 11/06/2012 11:53 AM, Srivatsa S. Bhat wrote:
> This is the main change - we keep the pageblocks in region-sorted order,
> where pageblocks belonging to region-0 come first, followed by those belonging
> to region-1 and so on. But the pageblocks within a given region need *not* be
> sorted, since we need them to be only region-sorted and not fully
> address-sorted.
>
> This sorting is performed when adding pages back to the freelists, thus
> avoiding any region-related overhead in the critical page allocation
> paths.
It's probably _better_ to do it at free time than alloc, but it's still
pretty bad to be doing a linear walk over a potentially 256-entry array
holding the zone lock. The overhead is going to show up somewhere. How
does this do with a kernel compile? Looks like exit() when a process
has a bunch of memory might get painful.
--
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