linux-kernel - Re: perf: Translating mmap2 ids into socket info?

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]

Date:	Wed, 22 Oct 2014 14:42:26 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Don Zickus <dzickus@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>, eranian@...gle.com,
	Andi Kleen <andi@...stfloor.org>, jolsa@...hat.com,
	jmario@...hat.com, rfowles@...hat.com
Subject: Re: perf:  Translating mmap2 ids into socket info?

Em Wed, Oct 22, 2014 at 06:45:10PM +0200, Peter Zijlstra escreveu:
> On Wed, Oct 22, 2014 at 12:20:26PM -0400, Don Zickus wrote:
> > Our cache-to-cache tool noticed the slowdown but we couldn't understand
> > why because we had falsely assumed the memory was allocated on the local
> > node but instead it was on the remote node.
 
> But in general, you can never say for user memory, since that has the
> process page table mapping in between, the user virtual address is
> unrelated to backing (and can change frequently and without
> notification).
 
> Therefore the mmap(2) information is useless for this, it only concerns
> user memory.

So what you are saying is that it is difficult to have some sort of
mechanism that an mmap moved from one node to another, when that
happens, i.e. a new tracepoint for that?

- Arnaldo
--
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/