linux-kernel - Re: [tip:sched/numa] sched/numa: Introduce sys_numa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 May 2012 11:00:46 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Rik van Riel <riel@...hat.com>, mingo@...nel.org, hpa@...or.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	pjt@...gle.com, bharata.rao@...il.com, akpm@...ux-foundation.org,
	Lee.Schermerhorn@...com, aarcange@...hat.com, danms@...ibm.com,
	suresh.b.siddha@...el.com, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/