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

    On Tue, Mar 31, 2009 at 8:17 PM, Hugh Dickins <> 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
    > 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.

    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
    More majordomo info at
    Please read the FAQ at

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