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:	Mon, 18 Nov 2013 19:33:11 -0700
From:	David Ahern <dsahern@...il.com>
To:	Namhyung Kim <namhyung@...nel.org>
CC:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-kernel@...r.kernel.org, jolsa@...hat.com,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 4/5] perf record: mmap output file - v5

On 11/18/13, 7:30 PM, Namhyung Kim wrote:
> On Mon, 18 Nov 2013 19:17:37 -0700, David Ahern wrote:
>> On 11/18/13, 7:13 PM, Namhyung Kim wrote:
>>> I think it should be
>>>
>>>     perf record -e cycles -F 4000 -e faults -c 1 --call-graph dwarf,8192 -a -- sleep 1
>>>
>>> (at least to generate the feedback spiral more efficiently..)
>>
>> you don't need the cycles. faults by itself works. Each event contains
>> 2 pages of data in the sample. With mmap-based output a single
>> sample (1 page fault in any process) generates 2-3 page faults by perf
>> which cause 2-3 >8k samples to be generated, which generates faults,
>> ....
>
> But after perf touches all pages in ring-buffer and stack, it won't
> generate page-faults for itself anymore, right?
>
> Hmm.. thinking it again, perf has all ring-buffer pages in memory when
> mmap() called, right?  If so why not doing something like MAP_POPULATE
> so that it doesn't need to generate minor-faults?

This is mmap'ed output, not the ring buffers or its stack. As the output 
file grows, new pages are needed and those are allocated on access via 
page faults. The ftruncate only extends the file size, it does not 
allocate pages at that time.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ