Re: [PATCH] mm/page_alloc: avoid hard lockups in __alloc_pages_bulk()

[Mel Gorman]

On Sat, Jul 10, 2021 at 10:57:53PM +0000, Zhang, Qiang wrote:
> ________________________________
> ??????: Matthew Wilcox <willy@xxxxxxxxxxxxx>
> ????????: ??????, ???? 11, 2021 05:10
> ??????: Andrew Morton
> ????: Zhang, Qiang; mgorman@xxxxxxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> ????: 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@xxxxxxxxxxxxx wrote:
> >
> > > From: Zqiang <qiang.zhang@xxxxxxxxxxxxx>
> > >
> > > 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@xxxxxxxxx

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