xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@linux.alibaba.com>
To: David Hildenbrand <david@redhat.com>
Cc: osalvador@suse.de, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-hyperv@vger.kernel.org,
	xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Alexander Duyck <alexander.h.duyck@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Michal Hocko <mhocko@kernel.org>, Mike Rapoport <rppt@kernel.org>,
	Scott Cheloha <cheloha@linux.ibm.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Vlastimil Babka <vbabka@suse.cz>, Wei Liu <wei.liu@kernel.org>,
	Wei Yang <richard.weiyang@linux.alibaba.com>
Subject: Re: [PATCH RFC 0/4] mm: place pages to the freelist tail when onling and undoing isolation
Date: Fri, 18 Sep 2020 10:30:51 +0800	[thread overview]
Message-ID: <20200918023051.GE54754@L-31X9LVDL-1304.local> (raw)
In-Reply-To: <DAC9E747-BDDF-41B6-A89B-604880DD7543@redhat.com>

On Wed, Sep 16, 2020 at 09:31:21PM +0200, David Hildenbrand wrote:
>
>
>> Am 16.09.2020 um 20:50 schrieb osalvador@suse.de:
>> 
>> On 2020-09-16 20:34, David Hildenbrand wrote:
>>> When adding separate memory blocks via add_memory*() and onlining them
>>> immediately, the metadata (especially the memmap) of the next block will be
>>> placed onto one of the just added+onlined block. This creates a chain
>>> of unmovable allocations: If the last memory block cannot get
>>> offlined+removed() so will all dependant ones. We directly have unmovable
>>> allocations all over the place.
>>> This can be observed quite easily using virtio-mem, however, it can also
>>> be observed when using DIMMs. The freshly onlined pages will usually be
>>> placed to the head of the freelists, meaning they will be allocated next,
>>> turning the just-added memory usually immediately un-removable. The
>>> fresh pages are cold, prefering to allocate others (that might be hot)
>>> also feels to be the natural thing to do.
>>> It also applies to the hyper-v balloon xen-balloon, and ppc64 dlpar: when
>>> adding separate, successive memory blocks, each memory block will have
>>> unmovable allocations on them - for example gigantic pages will fail to
>>> allocate.
>>> While the ZONE_NORMAL doesn't provide any guarantees that memory can get
>>> offlined+removed again (any kind of fragmentation with unmovable
>>> allocations is possible), there are many scenarios (hotplugging a lot of
>>> memory, running workload, hotunplug some memory/as much as possible) where
>>> we can offline+remove quite a lot with this patchset.
>> 
>> Hi David,
>> 
>
>Hi Oscar.
>
>> I did not read through the patchset yet, so sorry if the question is nonsense, but is this not trying to fix the same issue the vmemmap patches did? [1]
>
>Not nonesense at all. It only helps to some degree, though. It solves the dependencies due to the memmap. However, it‘s not completely ideal, especially for single memory blocks.
>
>With single memory blocks (virtio-mem, xen-balloon, hv balloon, ppc dlpar) you still have unmovable (vmemmap chunks) all over the physical address space. Consider the gigantic page example after hotplug. You directly fragmented all hotplugged memory.
>
>Of course, there might be (less extreme) dependencies due page tables for the identity mapping, extended struct pages and similar.
>
>Having that said, there are other benefits when preferring other memory over just hotplugged memory. Think about adding+onlining memory during boot (dimms under QEMU, virtio-mem), once the system is up you will have most (all) of that memory completely untouched.
>
>So while vmemmap on hotplugged memory would tackle some part of the issue, there are cases where this approach is better, and there are even benefits when combining both.

While everything changes with shuffle.

>
>Thanks!
>
>David
>
>> 
>> I was about to give it a new respin now that thw hwpoison stuff has been settled.
>> 
>> [1] https://patchwork.kernel.org/cover/11059175/
>> 

-- 
Wei Yang
Help you, Help me


  reply	other threads:[~2020-09-18  2:31 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16 18:34 [PATCH RFC 0/4] mm: place pages to the freelist tail when onling and undoing isolation David Hildenbrand
2020-09-16 18:34 ` [PATCH RFC 1/4] mm/page_alloc: convert "report" flag of __free_one_page() to a proper flag David Hildenbrand
2020-09-16 21:44   ` Alexander Duyck
2020-09-18  1:53   ` Wei Yang
2020-09-18  7:23     ` David Hildenbrand
2020-09-24 10:19   ` Vlastimil Babka
2020-09-25 10:34   ` Oscar Salvador
2020-09-16 18:34 ` [PATCH RFC 2/4] mm/page_alloc: place pages to tail in __putback_isolated_page() David Hildenbrand
2020-09-16 21:50   ` Alexander Duyck
2020-09-18  2:07   ` Wei Yang
2020-09-18  7:27     ` David Hildenbrand
2020-09-21  1:57       ` Wei Yang
2020-09-18  2:16   ` Wei Yang
2020-09-18  7:29     ` David Hildenbrand
2020-09-24 10:37   ` Vlastimil Babka
2020-09-25  8:10     ` David Hildenbrand
2020-09-25 13:19   ` Oscar Salvador
2020-09-25 13:30     ` David Hildenbrand
2020-09-16 18:34 ` [PATCH RFC 3/4] mm/page_alloc: always move pages to the tail of the freelist in unset_migratetype_isolate() David Hildenbrand
2020-09-18  2:29   ` Wei Yang
2020-09-18  7:30     ` David Hildenbrand
2020-09-24 11:13   ` Vlastimil Babka
2020-09-25  2:45     ` Wei Yang
2020-09-25  8:05       ` David Hildenbrand
2020-09-25  8:39         ` Vlastimil Babka
2020-09-25 13:57   ` Oscar Salvador
2020-09-16 18:34 ` [PATCH RFC 4/4] mm/page_alloc: place pages to tail in __free_pages_core() David Hildenbrand
2020-09-24 13:44   ` Vlastimil Babka
2020-09-28  7:58   ` Oscar Salvador
2020-09-28  8:36     ` David Hildenbrand
2020-09-28 12:53       ` Oscar Salvador
2020-09-16 18:50 ` [PATCH RFC 0/4] mm: place pages to the freelist tail when onling and undoing isolation osalvador
2020-09-16 19:31   ` David Hildenbrand
2020-09-18  2:30     ` Wei Yang [this message]
2020-09-18  7:32       ` David Hildenbrand
2020-09-23 14:31     ` Vlastimil Babka
2020-09-23 15:26       ` David Hildenbrand
2020-09-24  9:40         ` Mel Gorman
2020-09-24  9:54           ` David Hildenbrand
2020-09-24 13:59         ` Vlastimil Babka
2020-09-24 14:29           ` David Hildenbrand
2020-09-24  1:57       ` Wei Yang

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=20200918023051.GE54754@L-31X9LVDL-1304.local \
    --to=richard.weiyang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=cheloha@linux.ibm.com \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=osalvador@suse.de \
    --cc=rppt@kernel.org \
    --cc=sthemmin@microsoft.com \
    --cc=vbabka@suse.cz \
    --cc=wei.liu@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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).