[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160127035215.GA7813@js1304-P5Q-DELUXE>
Date: Wed, 27 Jan 2016 12:52:15 +0900
From: Joonsoo Kim <iamjoonsoo.kim@....com>
To: Dan Williams <dan.j.williams@...el.com>
Cc: 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>, Mel Gorman <mgorman@...e.de>,
"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 07:23:59PM -0800, Dan Williams wrote:
> On Tue, Jan 26, 2016 at 6:15 PM, Joonsoo Kim <iamjoonsoo.kim@....com> wrote:
> > On Tue, Jan 26, 2016 at 05:37:38PM -0800, Dan Williams wrote:
> >> On Tue, Jan 26, 2016 at 5:18 PM, Joonsoo Kim <iamjoonsoo.kim@....com> wrote:
> [..]
> >> > 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.
> >
> > Hmm... I'm not sure it's possible or not, but, it looks not a general
> > solution. It will solve your problem because you are using 64 bit arch
> > but other 32 bit archs can't get the benefit.
>
> This is where the ZONE_CMA and ZONE_DEVICE efforts diverge.
> ZONE_DEVICE is meant to enable DMA access to hundreds of gigagbytes of
> persistent memory. A 64-bit-only limitation for ZONE_DEVICE is
> reasonable.
Yes, but, my point is that if someone need another zone like as
ZONE_CMA, they couldn't get the benefit from this change. They need to
re-investigate what bits they can reduce and need to re-do all things.
If it is implemented more generally at this time, it can relieve their
burden and less churn the code. It would be helpful for maintainability.
Thanks.
Powered by blists - more mailing lists