Re: [RFC PATCH] mm: support CONFIG_ZONE_DEVICE + CONFIG_ZONE_DMA

[Dan Williams]

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