lkml.org 
[lkml]   [2009]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: add_to_swap_cache with GFP_ATOMIC ?
    From
    Thanks for quick reply.

    On Tue, Mar 31, 2009 at 8:17 PM, Hugh Dickins <hugh@veritas.com> wrote:
    > On Tue, 31 Mar 2009, Minchan Kim wrote:
    >>
    >> I don't know why we should call add_to_swap_cache with GFP_ATOMIC ?
    >> Is there a special something for avoiding blocking?
    >
    > add_to_swap_cache itself does not need to be called with GFP_ATOMIC.
    >
    > There are three places from which it is called:
    >
    > read_swap_cache_async (typically used when faulting) masks the
    > gfp_mask coming in (typically GFP_HIGHUSER_MOVABLE for the pages
    > themselves) to call add_to_swap_cache typically with GFP_KERNEL.
    >
    > shmem_writepage does call it with GFP_ATOMIC: that's because it's
    > holding the shmem_inode's spin_lock while it switches the page between
    > file cache and swap cache - IIRC holding page lock isn't quite enough
    > for that, because of other cases; but I've not thought that through
    > in a long time, we could re-examine if it troubles you.

    Yes. My point was that. but I am not sure what are other cases. :(
    Now, It don't hurt me but not sure in future.

    > The questionable one is add_to_swap (when vmscanning), which calls
    > it with __GFP_HIGH|__GFP_NOMEMALLOC|__GFP_NOWARN, i.e. GFP_ATOMIC
    > plus __GFP_NOMEMALLOC|__GFP_NOWARN.  That one I have wondered
    > about from time to time: GFP_NOIO would be the obvious choice,
    > that's what swap_writepage will use to allocate bio soon after.
    >
    > I've been tempted to change it, but afraid to touch that house
    > of cards, and afraid of long testing and justification required.
    > Would it be safe to drop that __GFP_HIGH?  What's the effect of the
    > __GFP_NOMEMALLOC (we've layer on layer of tweak this one way because
    > we're in the reclaim path so let it eat more, then tweak it the other
    > way because we don't want it to eat up _too_ much).  I just let it stay.

    Sigh.
    What a complex thing to change one line.
    Thanks for kind explanation.

    > Hugh
    >



    --
    Kinds regards,
    Minchan Kim
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-03-31 13:33    [W:0.024 / U:2.484 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site