linux-kernel - Re: [PATCHv3 00/19] perf tools: Factor ordered samples queue

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, 21 Jul 2014 15:09:07 +0300
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Jiri Olsa <jolsa@...hat.com>
CC:	Jiri Olsa <jolsa@...nel.org>, linux-kernel@...r.kernel.org,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Jean Pihet <jean.pihet@...aro.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCHv3 00/19] perf tools: Factor ordered samples queue

On 07/21/2014 12:54 PM, Jiri Olsa wrote:
> On Mon, Jul 21, 2014 at 11:47:35AM +0300, Adrian Hunter wrote:
> 
> SNIP
> 
>>>>> If PERF_RECORD_FINISHED_ROUND is missing the queue will
>>>>
>>>> Why is it missing?
>>>
>>> it's stored only for tracepoints now patch 17 fixies that
>>
>> Wouldn't that make a huge difference all by itself?
>>
>> I would make that the first patch, and measure the difference
>> that it makes by itself.
> 
> yes, that makes the difference.. still I think it's good to control
> perf memory allocation and do not let it take gigabytes just because
> this event is missing
> 
>>>> How do you know the results are still valid?  Wouldn't it
>>>> be better to wait that extra 15% and know that the data has
>>>> been processed correctly?
>>>
>>> The HALF flush could cause the out of order message
>>> (which I get occasionaly anyway). Patch 19 allows
>>
>> Occasional out-of-order messages would be worth investigating
>> IMHO.  Either there is a bug or there is some "interesting"
>> data being recorded.
> 
> I've got it via 'perf timechart record -I' sometimes:
> 
> [jolsa@...-x3650m4-01 perf]$ sudo ./perf timechart record -I
> ^C[ perf record: Woken up 337 times to write data ]
> [ perf record: Captured and wrote 290.256 MB perf.data (~12681486 samples) ]
> Warning:
> Processed 3365931 events and lost 1 chunks!
> 
> Check IO/CPU overload!
> 
> [jolsa@...-x3650m4-01 perf]$ sudo ./perf report --stdio
> Timestamp below last timeslice flush
> 0x2276f58 [0x68]: failed to process type: 9
> # To display the perf.data header info, please use --header/--header-only options.
> #
> 
> I think the reaon might be that one of the CPU mmap buffer
> is behind and got data after the round finishes for its
> timestamp.. but I haven't checked deeply on this yet
> 
>>
>>> out of order events after HALF flush.
>>>
>>> The main reason for me was to control the memory allocation,
>>> which could get enormous without ROUND events being stored.
>>
>> But now you are storing them...
>>
>>> The 100MB queue limit seems to be enough not to hit out of
>>> order event due to the HALF flush.
>>
>> ...so is the 100MB limit needed at all if you have ROUND
>> events?
> 
> for data files captured without the ROUND events fix

I am not sure it should be the default then, if it is
not needed going forward.

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