linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
To: linux-mm@kvack.org, akpm@linux-foundation.org
Cc: pavel.tatashin@microsoft.com, mhocko@suse.com,
	dave.jiang@intel.com, alexander.h.duyck@linux.intel.com,
	linux-kernel@vger.kernel.org, willy@infradead.org,
	davem@davemloft.net, yi.z.zhang@linux.intel.com,
	khalid.aziz@oracle.com, rppt@linux.vnet.ibm.com, vbabka@suse.cz,
	sparclinux@vger.kernel.org, dan.j.williams@intel.com,
	ldufour@linux.vnet.ibm.com, mgorman@techsingularity.net,
	mingo@kernel.org, kirill.shutemov@linux.intel.com
Subject: [mm PATCH v2 4/6] mm: Do not set reserved flag for hotplug memory
Date: Thu, 11 Oct 2018 15:13:51 -0700	[thread overview]
Message-ID: <20181011221351.1925.67694.stgit@localhost.localdomain> (raw)
In-Reply-To: <20181011221237.1925.85591.stgit@localhost.localdomain>

The general suspicion at this point is that the setting of the reserved bit
is not really needed for hotplug memory. In addition the setting of this
bit results in issues for DAX in that it is not possible to assign the
region to KVM if the reserved bit is set in each page.

For now we can try just not setting the bit since we suspect it isn't
adding value in setting it. If at a later time we find that it is needed we
can come back through and re-add it for the hotplug paths.

Suggested-by: Michael Hocko <mhocko@suse.com>
Reported-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 mm/page_alloc.c |   11 -----------
 1 file changed, 11 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3603d5444865..e435223e2ddb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5571,8 +5571,6 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
 
 		page = pfn_to_page(pfn);
 		__init_single_page(page, pfn, zone, nid);
-		if (context == MEMMAP_HOTPLUG)
-			__SetPageReserved(page);
 
 		/*
 		 * Mark the block movable so that blocks are reserved for
@@ -5626,15 +5624,6 @@ void __ref memmap_init_zone_device(struct zone *zone,
 		__init_single_page(page, pfn, zone_idx, nid);
 
 		/*
-		 * Mark page reserved as it will need to wait for onlining
-		 * phase for it to be fully associated with a zone.
-		 *
-		 * We can use the non-atomic __set_bit operation for setting
-		 * the flag as we are still initializing the pages.
-		 */
-		__SetPageReserved(page);
-
-		/*
 		 * ZONE_DEVICE pages union ->lru with a ->pgmap back
 		 * pointer and hmm_data.  It is a bug if a ZONE_DEVICE
 		 * page is ever freed or placed on a driver-private list.


  parent reply	other threads:[~2018-10-11 22:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11 22:13 [mm PATCH v2 0/6] Deferred page init improvements Alexander Duyck
2018-10-11 22:13 ` [mm PATCH v2 1/6] mm: Use mm_zero_struct_page from SPARC on all 64b architectures Alexander Duyck
2018-10-13 16:58   ` Pavel Tatashin
2018-10-13 17:18     ` Alexander Duyck
2018-10-13 17:49       ` Pavel Tatashin
2018-10-13 18:46         ` Alexander Duyck
2018-10-11 22:13 ` [mm PATCH v2 2/6] mm: Drop meminit_pfn_in_nid as it is redundant Alexander Duyck
2018-10-11 22:13 ` [mm PATCH v2 3/6] mm: Use memblock/zone specific iterator for handling deferred page init Alexander Duyck
2018-10-11 22:13 ` Alexander Duyck [this message]
2018-10-11 22:58   ` [mm PATCH v2 4/6] mm: Do not set reserved flag for hotplug memory Dan Williams
2018-10-11 23:22     ` Alexander Duyck
2018-10-11 22:13 ` [mm PATCH v2 5/6] mm: Move hot-plug specific memory init into separate functions and optimize Alexander Duyck
2018-10-11 22:14 ` [mm PATCH v2 6/6] mm: Use common iterator for deferred_init_pages and deferred_free_pages Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181011221351.1925.67694.stgit@localhost.localdomain \
    --to=alexander.h.duyck@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=davem@davemloft.net \
    --cc=khalid.aziz@oracle.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=ldufour@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=mingo@kernel.org \
    --cc=pavel.tatashin@microsoft.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yi.z.zhang@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).