[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18593.22748.791219.689521@notabene.brown>
Date: Tue, 12 Aug 2008 19:33:16 +1000
From: Neil Brown <neilb@...e.de>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
netdev@...r.kernel.org, trond.myklebust@....uio.no,
Daniel Lezcano <dlezcano@...ibm.com>,
Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [PATCH 02/30] mm: gfp_to_alloc_flags()
On Tuesday August 12, a.p.zijlstra@...llo.nl wrote:
> On Tue, 2008-08-12 at 15:01 +1000, Neil Brown wrote:
> > Did I miss something?
> > If I did, maybe more text in the changelog entry (or the comment)
> > would help.
>
> Ok, so the old code did:
>
> if (((p->flags & PF_MEMALLOC) || ...) && !in_interrupt) {
> ....
> goto nopage;
> }
>
> which avoid anything that has PF_MEMALLOC set from entering into direct
> reclaim, right?
>
> Now, the new code reads:
>
> if (alloc_flags & ALLOC_NO_WATERMARK) {
> }
>
> Which might be false, even though we have PF_MEMALLOC set -
> __GFP_NOMEMALLOC comes to mind.
>
> So we have to stop that recursion from happening.
>
> so we add:
>
> if (p->flags & PF_MEMALLOC)
> goto nopage;
>
> Now, if it were done before the !wait check, we'd have to consider
> atomic contexts, but as those are - as you rightly pointed out - handled
> by the !wait case, we can plainly do this check.
>
>
Oh yes, obvious when you explain it, thanks.
cat << END >> Changelog
As the test
- if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
- && !in_interrupt()) {
- if (!(gfp_mask & __GFP_NOMEMALLOC)) {
has been replaced with a slightly strong
+ if (alloc_flags & ALLOC_NO_WATERMARKS) {
we need to ensure we don't recurse when PF_MEMALLOC is set
END
??
Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists