All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: "Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	Oscar Salvador <osalvador@suse.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>
Subject: Re: [PATCH RFC] mm: Avoid triggering oom-killer during memory hot-remove operations
Date: Mon, 29 Jul 2024 11:16:11 +0200	[thread overview]
Message-ID: <Zqdd25XhcEDPEQIS@tiehlicka> (raw)
In-Reply-To: <280af822-577f-468b-953f-b70190551b6f@fujitsu.com>

On Mon 29-07-24 08:53:11, Zhijian Li (Fujitsu) wrote:
[...]
> >>>> [13853.758192] pagefault_out_of_memory: 4055 callbacks suppressed
> >>>> [13853.758243] Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF
> >>>
> >>> This shouldn't really happen and it indicates that some memory
> >>> allocation in the pagefault path has failed.
> >>
> >> May I know if this will cause side effect to other processes.
> > 
> > This eill mean that the #PF handler has failed to allocate memory and
> > the VM_FAULT_OOM error has unwound all the way up to the exception
> > handler and that will restart the instruction that has caused the #PF.
> > > In essence, as long as the process triggering this is not killed or the
> > allocation doesn't suceed it will be looping in the #PF path. This
> > normally doesn't happen because our allocators do not fail for small
> > allocation requests.
> 
> Thanks again for your detailed explanation.
> 
> I think this is acceptable for the process bound to the being removed node, isn't it?

It shouldn't be happening really. This is a sign that something doesn't
behave properly. E.g. some of the #PF returning VM_FAULT_OOM without
calling into the allocator.

-- 
Michal Hocko
SUSE Labs


      reply	other threads:[~2024-07-29  9:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-26  8:44 [PATCH RFC] mm: Avoid triggering oom-killer during memory hot-remove operations Li Zhijian
2024-07-26  9:17 ` Michal Hocko
2024-07-29  0:37   ` Zhijian Li (Fujitsu)
2024-07-29  2:14     ` Zhijian Li (Fujitsu)
2024-07-29  6:13       ` Michal Hocko
2024-07-29  6:34         ` Zhijian Li (Fujitsu)
2024-07-29  7:40           ` Michal Hocko
2024-07-29  8:04             ` Zhijian Li (Fujitsu)
2024-07-29  8:15               ` Michal Hocko
2024-07-29  8:53                 ` Zhijian Li (Fujitsu)
2024-07-29  9:16                   ` Michal Hocko [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=Zqdd25XhcEDPEQIS@tiehlicka \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lizhijian@fujitsu.com \
    --cc=osalvador@suse.de \
    --cc=y-goto@fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.