linux-kernel - Re: [PATCH] Perf: Correct Assumptions about Sample Timestamps in Passes

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: <528490DE.4080204@tu-dresden.de>
Date:	Thu, 14 Nov 2013 09:59:10 +0100
From:	Joseph Schuchart <joseph.schuchart@...dresden.de>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	thomas.ilsche@...dresden.de, linux-kernel@...r.kernel.org,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	David Ahern <dsahern@...il.com>
Subject: Re: [PATCH] Perf: Correct Assumptions about Sample Timestamps in
 Passes

> Just a quick side note, while I realize that you are 
> (rightfully!) concerned about correctness primarily, if that loop 
> over MAX_NR_CPUS executes often enough then this might hurt 
> performance:
> 
>    perf.h:#define MAX_NR_CPUS                      256
> 
> So it might be better to maintain a rolling min_max_timestamp in 
> this place:
> 
> +       os->max_timestamps[sample->cpu] = timestamp;
> 
> ?
> 
> If done that way then AFAICS we could even eliminate the 
> ->max_timestamps[NR_CPUS] array.

I can understand your performance concerns. However, I am not sure how
we can determine the minimal max_timestamp of all cpus without storing
the information on a per-cpu basis first. Accumulating it on the fly
would only lead to a global max_timestamp. If we had any information
about the number of CPUs, we could limit the number of iterations in
set_next_flush() to a minimum, though. However, that would require
keeping track of the maximum cpu id while reading the samples. Or is
there an easy way to determine the actual number cpus in the trace?

Thanks
Joseph

> 
> Thanks,
> 
> 	Ingo
> 
--
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/