[lkml]   [2008]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/4] Reclaim page capture v4
    Hi, Andy.

    I tested your patch in my desktop.
    The test is just kernel compile with single thread.
    My system environment is as follows.

    model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
    MemTotal: 2065856 kB

    When I tested vanilla, compile time is as follows.

    2433.53user 187.96system 42:05.99elapsed 103%CPU (0avgtext+0avgdata
    588752inputs+4503408outputs (127major+55456246minor)pagefaults 0swaps

    When I tested your patch, as follows.

    2489.63user 202.41system 44:47.71elapsed 100%CPU (0avgtext+0avgdata
    538608inputs+4503928outputs (130major+55531561minor)pagefaults 0swaps

    Regresstion almost is above 2 minutes.
    Do you think It is a trivial?

    I know your patch is good to allocate hugepage.
    But, I think many users don't need it, including embedded system and
    desktop users yet.

    So I suggest you made it enable optionally.

    On Wed, Oct 1, 2008 at 9:30 PM, Andy Whitcroft <> wrote:
    > For sometime we have been looking at mechanisms for improving the availability
    > of larger allocations under load. One of the options we have explored is
    > the capturing of pages freed under direct reclaim in order to increase the
    > chances of free pages coelescing before they are subject to reallocation
    > by racing allocators.
    > Following this email is a patch stack implementing page capture during
    > direct reclaim. It consits of four patches. The first two simply pull
    > out existing code into helpers for reuse. The third makes buddy's use
    > of struct page explicit. The fourth contains the meat of the changes,
    > and its leader contains a much fuller description of the feature.
    > This update represents a rebase to -mm and incorporates feedback from
    > KOSAKI Motohiro. It also incorporates an accounting fix which was
    > preventing some captures.
    > I have done a lot of comparitive testing with and without this patch
    > set and in broad brush I am seeing improvements in hugepage allocations
    > (worst case size) success on all of my test systems. These tests consist
    > of placing a constant stream of high order allocations on the system,
    > at varying rates. The results for these various runs are then averaged
    > to give an overall improvement.
    > Absolute Effective
    > x86-64 2.48% 4.58%
    > powerpc 5.55% 25.22%
    > x86-64 has a relatively small huge page size and so is always much more
    > effective at allocating huge pages. Even there we get a measurable
    > improvement. On powerpc the huge pages are much larger and much harder
    > to recover. Here we see a full 25% increase in page recovery.
    > It should be noted that these are worst case testing, and very agressive
    > taking every possible page in the system. It would be helpful to get
    > wider testing in -mm.
    > Against: 2.6.27-rc1-mm1
    > Andrew, please consider for -mm.
    > -apw
    > Changes since V3:
    > - Incorporates an anon vma fix pointed out by MinChan Kim
    > - switch to using a pagevec for page capture collection
    > Changes since V2:
    > - Incorporates review feedback from Christoph Lameter,
    > - Incorporates review feedback from Peter Zijlstra, and
    > - Checkpatch fixes.
    > Changes since V1:
    > - Incorporates review feedback from KOSAKI Motohiro,
    > - fixes up accounting when checking watermarks for captured pages,
    > - rebase 2.6.27-rc1-mm1,
    > - Incorporates review feedback from Mel.
    > Andy Whitcroft (4):
    > pull out the page pre-release and sanity check logic for reuse
    > pull out zone cpuset and watermark checks for reuse
    > buddy: explicitly identify buddy field use in struct page
    > capture pages freed during direct reclaim for allocation by the
    > reclaimer
    > include/linux/mm_types.h | 4 +
    > include/linux/page-flags.h | 4 +
    > include/linux/pagevec.h | 1 +
    > mm/internal.h | 7 +-
    > mm/page_alloc.c | 265 ++++++++++++++++++++++++++++++++++++++------
    > mm/vmscan.c | 118 ++++++++++++++++----
    > 6 files changed, 343 insertions(+), 56 deletions(-)
    > --
    > 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

    Kinds regards,
    MinChan Kim

     \ /
      Last update: 2008-10-02 04:49    [W:0.045 / U:5.504 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site