lkml.org 
[lkml]   [2012]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [tip:sched/numa] sched/numa: Introduce sys_numa_{t,m}bind()
    On Fri, 18 May 2012, Peter Zijlstra wrote:

    > On Fri, 2012-05-18 at 10:47 -0500, Christoph Lameter wrote:
    > > On Fri, 18 May 2012, Peter Zijlstra wrote:
    > >
    > > > On Fri, 2012-05-18 at 17:35 +0200, Peter Zijlstra wrote:
    > > > > I've also said many times over that I absolutely detest all the async
    > > > > stuff because it messes up accounting. And until someone comes up with a
    > > > > sane means of sorting that I'll stick to migrate-on-fault.
    > > >
    > > > The other nice advantage of migrate-on-fault is that you don't have to
    > > > play lifetime games with vmas. This much simplifies that aspect.
    > >
    > > The problem with migrate on fault in the past has been that there was no
    > > consistent benefit from the overhead added to the system. Useless page
    > > migration is a bit expensive.
    >
    > I'm not sure I follow.. having the page local is a win, presuming you
    > can limit the migration rate to something low in relation to the cost of
    > remote accesses.

    Having the page local is a win if there are a sufficient number of
    accesses to amortize the effort to move the page. Given the expensive
    nature of page migration there would need to be a large number of accesses
    to a page to justify the effort.

    > How does it matter how you migrate?

    Migrate on fault incurs two types of costs:

    1. Unmapping. This results in additional faults to reestablish the ptes.

    2. Actual lazy migrate. More faults. Now the page needs to be copied to
    the new node and the actual migration work is done.



    \
     
     \ /
      Last update: 2012-05-18 18:41    [W:6.856 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site