[PATCH Xenial 4.4] UBUNTU: [Config] CONFIG_ZONE_DEVICE=y for amd64]
Mark
markk at clara.co.uk
Mon Mar 28 19:49:39 UTC 2016
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>
More information about the kernel-team
mailing list