linux-kernel - Re: [PATCH -rt 2/3] Make trace

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-next>] [day] [month] [year] [list]

Message-ID: <20061205221046.GB20587@elte.hu>
Date:	Tue, 5 Dec 2006 23:10:46 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Karsten Wiese <fzu@...gehoertderstaat.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -rt 2/3] Make trace_freerunning work

* Karsten Wiese <fzu@...gehoertderstaat.de> wrote:

> Only reorder trace entries once if trace_freerunning is 1. Modify 
> user_trace_stop() not to check report_latency(delta) then. Note that 
> at least MAX_TRACE entries must have been generated between 
> user_trace_start() and user_trace_stop() for a freerunning trace to be 
> reliable.

my thinking behind the freerunning feature is this:

freerunning should behave the same way with regard to latency 
measurement. I.e. report_latency() is still needed, and the kernel will 
thus do a maximum search over all traces triggered via start/stop.

the difference is in the recording of the last-largest-latency:

- with !freerunning, the tracer stops recording after MAX_TRACE entries, 
  i.e. the "head" of the trace is preserved in the trace buffer.

- with freerunning, the tracer never stops, it 'wraps around' after 
  MAX_TRACE entries and starts overwriting the oldest entries. I.e. the  
  "tail" of the trace is preserved in the trace buffer.

depending on the situation, freerunning or !freerunning might be the 
more useful mode.

but there should be no difference in measurement.

could you try to rework this patch with the above functionality in mind? 
(or if you'd like to see new functionality, what would that be - and we 
could/should implement that separately from the existing semantics of 
freerunning and !freerunning)

	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/