linux-kernel - Re: [RFC][PATCH 00/26] sched/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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1332158367.18960.308.camel@twins>
Date:	Mon, 19 Mar 2012 12:59:27 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Avi Kivity <avi@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, Paul Turner <pjt@...gle.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Mike Galbraith <efault@....de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Dan Smith <danms@...ibm.com>,
	Bharata B Rao <bharata.rao@...il.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC][PATCH 00/26] sched/numa

On Mon, 2012-03-19 at 13:42 +0200, Avi Kivity wrote:
> > Now if you want to be able to scan per-thread, you need per-thread
> > page-tables and I really don't want to ever see that. That will blow
> > memory overhead and context switch times.
> 
> I thought of only duplicating down to the PDE level, that gets rid of
> almost all of the overhead. 

You still get the significant CR3 cost for thread switches. 

[ /me grabs the SDM to find that PDE is what we in Linux call the pmd ]

That'll cut the memory overhead down but also the severely impact the
accuracy.

Also, I still don't see how such a scheme would correctly identify
per-cpu memory in guest kernels. While less frequent its still very
common to do remote access to per-cpu data. So even if you did page
granularity you'd get a fair amount of pages that are accesses by all
threads (vcpus) in the scan interval, even thought they're primarily
accesses by just one.

If you go to pmd level you get even less information.
--
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/