[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160127074640.GG3104@suse.de>
Date: Wed, 27 Jan 2016 07:46:40 +0000
From: Mel Gorman <mgorman@...e.de>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
linux-nvdimm <linux-nvdimm@...1.01.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@....de>, Linux MM <linux-mm@...ck.org>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Jerome Glisse <j.glisse@...il.com>,
Sudip Mukherjee <sudipm.mukherjee@...il.com>
Subject: Re: [RFC PATCH] mm: support CONFIG_ZONE_DEVICE + CONFIG_ZONE_DMA
On Tue, Jan 26, 2016 at 05:37:38PM -0800, Dan Williams wrote:
> >> Will do, especially since other efforts are feeling the pinch on the
> >> MAX_NR_ZONES limitation.
> >
> > Please refer my previous attempt to add a new zone, ZONE_CMA.
> >
> > https://lkml.org/lkml/2015/2/12/84
> >
> > It salvages a bit from SECTION_WIDTH by increasing section size.
> > Similarly, I guess we can reduce NODE_WIDTH if needed although
> > it could cause to reduce maximum node size.
>
> Dave pointed out to me that LAST__PID_SHIFT might be a better
> candidate to reduce to 7 bits. That field is for storing pids which
> are already bigger than 8 bits. If it is relying on the fact that
> pids don't rollover very often then likely the impact of 7-bits
> instead of 8 will be minimal.
It's not relying on the fact pids don't roll over very often. The
information is used by automatic NUMA balancing to detect if multiple
accesses to data are from the same task or not. Reducing the number of
bits it uses increases the chance that two tasks will both think they are
the data owner and keep migrating it.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists