lkml.org 
[lkml]   [2008]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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


\
 
 \ /
  Last update: 2008-08-12 11:37    [W:0.058 / U:2.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site