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
