lkml.org 
[lkml]   [2021]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm/page_alloc: avoid hard lockups in __alloc_pages_bulk()
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

\
 
 \ /
  Last update: 2021-07-15 10:36    [W:0.044 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site