lkml.org 
[lkml]   [2010]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 61 of 66] use compaction for GFP_ATOMIC order > 0
    On Tue, Nov 09, 2010 at 07:27:37PM +0900, KOSAKI Motohiro wrote:
    > > From: Andrea Arcangeli <aarcange@redhat.com>
    > >
    > > This takes advantage of memory compaction to properly generate pages of order >
    > > 0 if regular page reclaim fails and priority level becomes more severe and we
    > > don't reach the proper watermarks.
    > >
    > > Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    >
    > First, I don't think this patch is related to GFP_ATOMIC. So, I think the
    > patch title is a bit misleading.
    >
    > Second, this patch has two changes. 1) remove PAGE_ALLOC_COSTLY_ORDER
    > threshold 2) implement background compaction. please separate them.

    Well the subject isn't entirely misleading: background compaction in
    kswapd is only for the GFP_ATOMIC so GFP_ATOMIC order >0 allocations
    are definitely related to this patch.

    Then I ended up then allowing compaction for all order of allocations
    as it doesn't make sense to fail order 2 for the kernel stack and
    succeed order 9 but it's true I can split that off, I will split it
    for #33, thanks for allowing me to clean up the stuff better.

    > Third, This patch makes a lot of PFN order page scan and churn LRU
    > aggressively. I'm not sure this aggressive lru shuffling is safe and
    > works effective. I hope you provide some demonstration and/or show
    > benchmark result.

    The patch will increase the amount of compaction for GFP_ATOMIC order
    >0, but it won't alter the amount of free pages in the system, but
    it'll satisfy the in-function-of order watermarks that are right now
    ignored. If user asked GFP_ATOMIC order > 0, this is what it asks,
    it's up to the user not to ask for it if it's not worthwhile. If user
    doesn't want this but it just wants to poll the LRU it should use
    GFP_ATOMIC|__GFP_NO_KSWAPD.

    The benchmark results I don't have at the moment but this has been
    tested with tg3 with jumbo packets that trigger order 2 allocation and
    no degradation was noticed. To be fair it didn't significantly improve
    the amount of order 2 (9046 bytes large skb) allocated from irq
    though, but I thought it was good idea to keep it in case there are
    less aggressive/frequent users doing similar things.

    Overall the more important part of the patch is the point 2) that I
    can make it cleaner by splitting it off as you noticed and I will do
    it.


    \
     
     \ /
      Last update: 2010-11-09 22:55    [W:6.565 / U:0.428 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site