From: Mel Gorman <mgorman@techsingularity.net>
To: "Zhang, Qiang" <Qiang.Zhang@windriver.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Uladzislau Rezki (Sony)" <urezki@gmail.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/page_alloc: avoid hard lockups in __alloc_pages_bulk()
Date: Thu, 15 Jul 2021 09:35:57 +0100 [thread overview]
Message-ID: <20210715083557.GP3809@techsingularity.net> (raw)
In-Reply-To: <BL1PR11MB54785E7EA2BFBDAA393F15BBFF179@BL1PR11MB5478.namprd11.prod.outlook.com>
On Sat, Jul 10, 2021 at 10:57:53PM +0000, Zhang, Qiang wrote:
> ________________________________
> ??????: Matthew Wilcox <willy@infradead.org>
> ????????: ??????, ???? 11, 2021 05:10
> ??????: Andrew Morton
> ????: Zhang, Qiang; mgorman@techsingularity.net; linux-mm@kvack.org; linux-kernel@vger.kernel.org
> ????: Re: [PATCH] mm/page_alloc: avoid hard lockups in __alloc_pages_bulk()
>
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On Sat, Jul 10, 2021 at 11:46:13AM -0700, Andrew Morton wrote:
> > On Sat, 10 Jul 2021 19:29:29 +0800 qiang.zhang@windriver.com wrote:
> >
> > > From: Zqiang <qiang.zhang@windriver.com>
> > >
> > > The __alloc_pages_bulk() mainly used for batch allocation of
> > > order-0 pages, in the case of holding pagesets.lock, if too
> > > many pages are required, maybe trigger hard lockup watchdog.
> >
> > Ouch. Has this been observed in testing? If so, can you please share
> > the kernel debug output from that event?
>
> >This should be fixed in the caller by asking for fewer pages.
> >The NFS and vmalloc cases have already been fixed for this.
>
> The NFS and vmalloc cases haven been fixed??
> I don??t see if there is any information about that?
>
AFAIK, NFS simply doesn't ask for a large enough number of pages to be
of concern. For vmalloc, it's somewhat theoritical that it can happen
for anything other than a stress test but this exists
https://lore.kernel.org/r/20210705170537.43060-1-urezki@gmail.com
I had no objection to the patch but didn't feel strongly enough to say
anything about it either given that it was triggered artifically.
--
Mel Gorman
SUSE Labs
prev parent reply other threads:[~2021-07-15 8:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-10 11:29 [PATCH] mm/page_alloc: avoid hard lockups in __alloc_pages_bulk() qiang.zhang
2021-07-10 18:46 ` Andrew Morton
2021-07-10 21:10 ` Matthew Wilcox
[not found] ` <BL1PR11MB54785E7EA2BFBDAA393F15BBFF179@BL1PR11MB5478.namprd11.prod.outlook.com>
2021-07-15 8:35 ` Mel Gorman [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=20210715083557.GP3809@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=Qiang.Zhang@windriver.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=urezki@gmail.com \
--cc=willy@infradead.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).