From: Joanne Koong <joannelkoong@gmail.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: David Hildenbrand <david@redhat.com>,
SeongJae Park <sj@kernel.org>,
miklos@szeredi.hu, linux-fsdevel@vger.kernel.org,
jefflexu@linux.alibaba.com, josef@toxicpanda.com,
linux-mm@kvack.org, bernd.schubert@fastmail.fm,
kernel-team@meta.com
Subject: Re: [PATCH v4 4/6] mm/memory-hotplug: add finite retries in offline_pages() if migration fails
Date: Fri, 8 Nov 2024 13:42:15 -0800 [thread overview]
Message-ID: <CAJnrk1Y-BRg6qyQoUvZW7mUfydp+cM1Rxtd_v0UaKOLuL9OUUQ@mail.gmail.com> (raw)
In-Reply-To: <ubpkgutgkm2te7tu3dyvjxxkcmhelawd24lyaqnxrbvzgj7psl@zli7u63w4qgu>
On Fri, Nov 8, 2024 at 1:27 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
>
> On Fri, Nov 08, 2024 at 08:00:25PM +0100, David Hildenbrand wrote:
> > On 08.11.24 19:56, David Hildenbrand wrote:
> > > On 08.11.24 18:33, SeongJae Park wrote:
> > > > + David Hildenbrand
> > > >
> > > > On Thu, 7 Nov 2024 15:56:12 -0800 Joanne Koong <joannelkoong@gmail.com> wrote:
> > > >
> > > > > In offline_pages(), do_migrate_range() may potentially retry forever if
> > > > > the migration fails. Add a return value for do_migrate_range(), and
> > > > > allow offline_page() to try migrating pages 5 times before erroring
> > > > > out, similar to how migration failures in __alloc_contig_migrate_range()
> > > > > is handled.
> > > >
> > > > I'm curious if this could cause unexpected behavioral differences to memory
> > > > hotplugging users, and how '5' is chosen. Could you please enlighten me?
> > > >
> > >
> > > I'm wondering how much more often I'll have to nack such a patch. :)
> >
> > A more recent discussion: https://lore.kernel.org/linux-mm/52161997-15aa-4093-a573-3bfd8da14ff1@fujitsu.com/T/#mdda39b2956a11c46f8da8796f9612ac007edbdab
> >
> > Long story short: this is expected and documented
>
> Thanks David for the background.
>
> Joanne, simply drop this patch. It is not required for your series.
Awesome, I'm happy to drop this patch.
Just curious though - don't we need this in order to mitigate the
scenario where if an unprivileged fuse server never completes
writeback, we don't run into this infinite loop? Or is it that memory
hotplugging is always initiated from userspace so if it does run into
an infinite loop (like also in that thread David linked), userspace is
responsible for sending a signal to terminate it?
Thanks,
Joanne
next prev parent reply other threads:[~2024-11-08 21:42 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-07 23:56 [PATCH v4 0/6] fuse: remove temp page copies in writeback Joanne Koong
2024-11-07 23:56 ` [PATCH v4 1/6] mm: add AS_WRITEBACK_MAY_BLOCK mapping flag Joanne Koong
2024-11-09 0:10 ` Shakeel Butt
2024-11-11 21:11 ` Joanne Koong
2024-11-15 19:33 ` Joanne Koong
2024-11-15 20:17 ` Joanne Koong
2024-11-07 23:56 ` [PATCH v4 2/6] mm: skip reclaiming folios in legacy memcg writeback contexts that may block Joanne Koong
2024-11-09 0:16 ` Shakeel Butt
2024-11-07 23:56 ` [PATCH v4 3/6] fs/writeback: in wait_sb_inodes(), skip wait for AS_WRITEBACK_MAY_BLOCK mappings Joanne Koong
2024-11-07 23:56 ` [PATCH v4 4/6] mm/memory-hotplug: add finite retries in offline_pages() if migration fails Joanne Koong
2024-11-08 17:33 ` SeongJae Park
2024-11-08 18:56 ` David Hildenbrand
2024-11-08 19:00 ` David Hildenbrand
2024-11-08 21:27 ` Shakeel Butt
2024-11-08 21:42 ` Joanne Koong [this message]
2024-11-08 22:16 ` Shakeel Butt
2024-11-08 22:20 ` Joanne Koong
2024-11-08 21:59 ` Joanne Koong
2024-11-07 23:56 ` [PATCH v4 5/6] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_MAY_BLOCK mappings Joanne Koong
2024-11-07 23:56 ` [PATCH v4 6/6] fuse: remove tmp folio for writebacks and internal rb tree Joanne Koong
2024-11-08 8:48 ` Jingbo Xu
2024-11-08 22:33 ` Joanne Koong
2024-11-11 8:32 ` Jingbo Xu
2024-11-11 21:30 ` Joanne Koong
2024-11-12 2:31 ` Jingbo Xu
2024-11-13 19:11 ` Joanne Koong
2024-11-12 9:25 ` Jingbo Xu
2024-11-14 0:39 ` Joanne Koong
2024-11-14 1:46 ` Jingbo Xu
2024-11-14 18:19 ` Joanne Koong
2024-11-15 2:18 ` Jingbo Xu
2024-11-15 18:29 ` Joanne Koong
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=CAJnrk1Y-BRg6qyQoUvZW7mUfydp+cM1Rxtd_v0UaKOLuL9OUUQ@mail.gmail.com \
--to=joannelkoong@gmail.com \
--cc=bernd.schubert@fastmail.fm \
--cc=david@redhat.com \
--cc=jefflexu@linux.alibaba.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@meta.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=shakeel.butt@linux.dev \
--cc=sj@kernel.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