linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: xen-devel@lists.xenproject.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	"Michal Hocko" <mhocko@suse.com>
Subject: Re: [PATCH v2] mm, page_alloc: fix build_zonerefs_node()
Date: Fri, 8 Apr 2022 07:50:04 +0200	[thread overview]
Message-ID: <fa36ede3-3f5c-e10c-107d-0e4fae4af098@suse.com> (raw)
In-Reply-To: <20220407154426.7076e19f5b80d927dd715de9@linux-foundation.org>


[-- Attachment #1.1.1: Type: text/plain, Size: 2004 bytes --]

On 08.04.22 00:44, Andrew Morton wrote:
> On Thu,  7 Apr 2022 14:06:37 +0200 Juergen Gross <jgross@suse.com> wrote:
> 
>> Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from
>> zones with pages managed by the buddy allocator")
> 
> Six years ago!
> 
>> only zones with free
>> memory are included in a built zonelist. This is problematic when e.g.
>> all memory of a zone has been ballooned out when zonelists are being
>> rebuilt.
>>
>> The decision whether to rebuild the zonelists when onlining new memory
>> is done based on populated_zone() returning 0 for the zone the memory
>> will be added to. The new zone is added to the zonelists only, if it
>> has free memory pages (managed_zone() returns a non-zero value) after
>> the memory has been onlined. This implies, that onlining memory will
>> always free the added pages to the allocator immediately, but this is
>> not true in all cases: when e.g. running as a Xen guest the onlined
>> new memory will be added only to the ballooned memory list, it will be
>> freed only when the guest is being ballooned up afterwards.
>>
>> Another problem with using managed_zone() for the decision whether a
>> zone is being added to the zonelists is, that a zone with all memory
>> used will in fact be removed from all zonelists in case the zonelists
>> happen to be rebuilt.
>>
>> Use populated_zone() when building a zonelist as it has been done
>> before that commit.
>>
>> Cc: stable@vger.kernel.org
> 
> Some details, please.  Is this really serious enough to warrant
> backporting?  Is some new workload/usage pattern causing people to hit
> this?

Yes. There was a report that QubesOS (based on Xen) is hitting this
problem. Xen has switched to use the zone device functionality in
kernel 5.9 and QubesOS wants to use memory hotplugging for guests in
order to be able to start a guest with minimal memory and expand it
as needed. This was the report leading to the patch.


Juergen


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

      reply	other threads:[~2022-04-08  5:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-07 12:06 [PATCH v2] mm, page_alloc: fix build_zonerefs_node() Juergen Gross
2022-04-07 12:14 ` Michal Hocko
2022-04-07 12:45 ` David Hildenbrand
2022-04-07 12:53   ` Juergen Gross
2022-04-07 22:44 ` Andrew Morton
2022-04-08  5:50   ` Juergen Gross [this message]

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=fa36ede3-3f5c-e10c-107d-0e4fae4af098@suse.com \
    --to=jgross@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marmarek@invisiblethingslab.com \
    --cc=mhocko@suse.com \
    --cc=stable@vger.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).