On Thu, Jun 19, 2014 at 12:03:40PM +1000, Dave Chinner wrote:
> On Fri, Jun 13, 2014 at 10:19:25AM -0400, Dave Jones wrote:
> > On Fri, Jun 13, 2014 at 04:26:45PM +1000, Dave Chinner wrote:
> > > > 970 if (WARN_ON_ONCE((current->flags &
> > > > (PF_MEMALLOC|PF_KSWAPD)) ==
> > > > 971 PF_MEMALLOC))
> > >
> > > What were you running at the time? The XFS warning is there to
> > > indicate that memory reclaim is doing something it shouldn't (i.e.
> > > dirty page writeback from direct reclaim), so this is one for the mm
> > > folk to work out...
> > Trinity had driven the machine deeply into swap, and the oom killer was
> > kicking in pretty often. Then this happened.
> Yup, sounds like a problem somewhere in mm/vmscan.c....
I'm now hitting this fairly often, and no-one seems to have offered up
any suggestions yet, so I'm going to flail and guess randomly until someone
has a better idea what could be wrong.
That WARN commentary for the benefit of linux-mm readers..
961 * Refuse to write the page out if we are called from reclaim
963 * This avoids stack overflows when called from deeply used stacks
964 * random callers for direct reclaim or memcg reclaim. We
965 * allow reclaim from kswapd as the stack usage there is
967 * This should never happen except in the case of a VM regression
968 * warn about it.
970 if (WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD)) ==
972 goto redirty;
Looking at this trace..
The reclaim here looks to be triggered from the readahead code.
Should something in that path be setting PF_KSWAPD in the gfp mask ?