linux-kernel - Re: [RFC PATCH] mm: support CONFIG_ZONE_DEVICE + CONFIG_ZONE

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:	Tue, 26 Jan 2016 20:26:24 -0800
From:	Dan Williams <dan.j.williams@...el.com>
To:	Joonsoo Kim <iamjoonsoo.kim@....com>
Cc:	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>,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>,
	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>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@....de>
Subject: Re: [RFC PATCH] mm: support CONFIG_ZONE_DEVICE + CONFIG_ZONE_DMA

On Tue, Jan 26, 2016 at 7:52 PM, Joonsoo Kim <iamjoonsoo.kim@....com> wrote:
> 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.

I agree in principle that finding a 32-bit compatible solution is
desirable, but it simply may not be feasible.

For now, I'll help with auditing the existing bits so we can enumerate
the tradeoffs.

Hmm, one tradeoff that comes to mind for 32-bit is sacrificing
ZONE_HIGHMEM, for ZONE_CMA.  Are there configurations that need both
enabled?  If a platform needs highmem it really should be using a
64-bit kernel (if possible), desire for ZONE_CMA might be a nice
encouragement to lessen the prevalence of highmem.