lkml.org 
[lkml]   [2009]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 0/4]: affinity-on-next-touch
    On Mon, May 11, 2009 at 04:54:40PM +0200, Stefan Lankes wrote:
    > > From: Andi Kleen [mailto:andi@firstfloor.org]
    > >
    > > Stefan Lankes <lankes@lfbs.rwth-aachen.de> writes:
    > > >
    > > > [Patch 1/4]: Extend the system call madvise with a new parameter
    > > > MADV_ACCESS_LWP (the same as used in Solaris). The specified memory
    > > area
    > >
    > > Linux does NUMA memory policies in mbind(), not madvise()
    > > Also if there's a new NUMA policy it should be in the standard
    > > Linux NUMA memory policy frame work, not inventing a new one
    >
    > By default, mbind only has an effect on new allocations. I think that this

    Nope, it affects existing pages too, it can even move pages
    if you ask for it.

    > is different from what we need for applications with dynamic memory access
    > patterns. The app gives the kernel a hint that the access pattern has been
    > changed and the kernel has to redistribute the pages which are already
    > allocated.

    MF_MOVE


    > For instance, Norden's PDE solvers using adaptive mesh refinements (AMR) [1]
    > is an application with a dynamic access pattern. We use this example to
    > evaluate the performance of our patch. We ran this solver on our
    > quad-socket, dual-core Opteron 875 (2.2GHz) system running CentOS 5.2. The
    > code was already optimized for NUMA architectures. Before the arrays are
    > initialized, the threads are bound to one core. In our test case, the solver
    > needs 5318s. If we use our kernel extension, the solver needs 4489s.

    Okay that sounds like good numbers.

    > Currently, we are testing some other apps.

    Please keep the list updated.

    -Andi
    --
    ak@linux.intel.com -- Speaking for myself only.


    \
     
     \ /
      Last update: 2009-05-11 18:35    [W:3.033 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site