Messages in this thread | | | From | Neil Brown <> | Date | Tue, 12 Aug 2008 19:33:16 +1000 | Subject | Re: [PATCH 02/30] mm: gfp_to_alloc_flags() |
| |
On Tuesday August 12, a.p.zijlstra@chello.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
| |