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.027 / U:1.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site