[PATCH Xenial 4.4] UBUNTU: [Config] CONFIG_ZONE_DEVICE=y for amd64]

[Tim Gardner]

On 03/28/2016 01:49 PM, Mark wrote:
> On Fri, January 29, 2016 16:50, Tim Gardner wrote:
>> On 01/27/2016 12:23 PM, Mark wrote:
>>> ...
>>> It seems there is some upstream discussion and an RFC patch (which did
>>> seem to fix the problem for me). That patch probably won't be committed
>>> as-is, but hopefully a solution will be found so this issue ceases to be
>>> a problem.
>>>
>>> http://www.spinics.net/lists/kernel/msg2170767.html
>>>
>>> I don't know whether any solution will get backported to kernel 4.4, but
>>> if not, perhaps backporting it could be one of the Ubuntu-specific
>>> kernel changes.
>>>
>>>
>>> Mark
>>
>> Well, that thread does hold some promise. Perhaps you could drop a note
>> on this list when something gets merged into a maintainer tree or even
>> linux-next.
> 
> It looks like a fix for this issue got committed to the mainline kernel:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b11a7b94100cba5ec926a181894c2897a22651b9
> 
> I don't know whether it's planned for that patch to be backported to the
> mainline 4.4.x kernel. But the patch looks fairly small/simple, so if not
> I hope it can be backported to the Ubuntu 16.04 kernel. It will avoid
> unnecessary hardware breakage when users install 16.04 final.
> 
> Commit message for the patch pasted below.
> 
> 
> mm: exclude ZONE_DEVICE from GFP_ZONE_TABLE
> 
> ZONE_DEVICE (merged in 4.3) and ZONE_CMA (proposed) are examples of new
> mm zones that are bumping up against the current maximum limit of 4
> zones, i.e.  2 bits in page->flags for the GFP_ZONE_TABLE.
> 
> The GFP_ZONE_TABLE poses an interesting constraint since
> include/linux/gfp.h gets included by the 32-bit portion of a 64-bit
> build.  We need to be careful to only build the table for zones that
> have a corresponding gfp_t flag.  GFP_ZONES_SHIFT is introduced for this
> purpose.  This patch does not attempt to solve the problem of adding a
> new zone that also has a corresponding GFP_ flag.
> 
> Vlastimil points out that ZONE_DEVICE, by depending on x86_64 and
> SPARSEMEM_VMEMMAP implies that SECTIONS_WIDTH is zero.  In other words
> even though ZONE_DEVICE does not fit in GFP_ZONE_TABLE it is free to
> consume another bit in page->flags (expand ZONES_WIDTH) with room to
> spare.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=110931
> Fixes: 033fbae988fc ("mm: ZONE_DEVICE for "device memory"")
> Signed-off-by: Dan Williams <dan.j.williams at intel.com>
> Reported-by: Mark <markk at clara.co.uk>
> Reported-by: Vlastimil Babka <vbabka at suse.cz>
> Cc: Mel Gorman <mgorman at suse.de>
> Cc: Rik van Riel <riel at redhat.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim at lge.com>
> Cc: Dave Hansen <dave.hansen at linux.intel.com>
> Cc: Sudip Mukherjee <sudipm.mukherjee at gmail.com>
> Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
> 
> 

I reverted the linux-next patch ('mm: CONFIG_NR_ZONES_EXTENDED') which
never made it upstream and cherry-picked
b11a7b94100cba5ec926a181894c2897a22651b9 ('mm: exclude ZONE_DEVICE from
GFP_ZONE_TABLE').

BugLink: http://bugs.launchpad.net/bugs/1563293

rtg
-- 
Tim Gardner tim.gardner at canonical.com