xfs
[Top] [All Lists]

Re: [PATCH] mm/vmscan: Do not block forever at shrink_inactive_list().

To: Dave Chinner <david@xxxxxxxxxxxxx>, Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>, riel@xxxxxxxxxx, kosaki.motohiro@xxxxxxxxxxxxxx, fengguang.wu@xxxxxxxxx, kamezawa.hiroyu@xxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Subject: Re: [PATCH] mm/vmscan: Do not block forever at shrink_inactive_list().
From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 19 May 2014 23:03:11 -0700
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140519225915.3370328d.akpm@xxxxxxxxxxxxxxxxxxxx>
References: <201405192340.FCD48964.OFQHOOJLVSFFMt@xxxxxxxxxxxxxxxxxxx> <20140520004449.GE18954@dastard> <20140519225915.3370328d.akpm@xxxxxxxxxxxxxxxxxxxx>
On Mon, 19 May 2014 22:59:15 -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 
wrote:

> On Tue, 20 May 2014 10:44:49 +1000 Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> 
> > @@ -258,14 +258,23 @@ xfs_bmapi_allocate_worker(
> >     struct xfs_bmalloca     *args = container_of(work,
> >                                             struct xfs_bmalloca, work);
> >     unsigned long           pflags;
> > +   unsigned long           new_pflags = PF_FSTRANS;
> >  
> > -   /* we are in a transaction context here */
> > -   current_set_flags_nested(&pflags, PF_FSTRANS);
> > +   /*
> > +    * we are in a transaction context here, but may also be doing work
> > +    * in kswapd context, and hence we may need to inherit that state
> > +    * temporarily to ensure that we don't block waiting for memory reclaim
> > +    * in any way.
> > +    */
> > +   if (args->kswapd)
> > +           new_pflags |= PF_MEMALLOC | PF_SWAPWRITE | PF_KSWAPD;
> 
> So current_is_kswapd() returns true for a thread which is not kswapd. 
> That's a bit smelly.
> 
> Should this thread really be incrementing KSWAPD_INODESTEAL instead of
> PGINODESTEAL, for example?  current_is_kswapd() does a range of things,
> only one(?) of which you actually want.
> 
> It would be cleaner to create a new PF_ flag to select just that
> behavior.  That's a better model than telling the world "I am magic and
> special".

Or a new __GFP_FLAG.

> But we're awfully close to running out of PF_ space and I don't know if
> this ugly justifies consuming a flag.
> 

<Prev in Thread] Current Thread [Next in Thread>