lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ