linux-kernel - Re: [PATCH 1/2] ftrace: single CPU tracers use CPU clock

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:	Sat, 26 Jul 2008 09:15:28 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 1/2] ftrace: single CPU tracers use CPU clock

On Sat, 26 Jul 2008, Ingo Molnar wrote:

>
> * Steven Rostedt <rostedt@...dmis.org> wrote:
>
> > The current ftrace clock uses the sched_clock.c code. This code tries
> > to handle cases where the TSC is out of sync between different CPUs.
> > Unfortunately, even with insync TSCs, due to drifts between the CPU
> > clock and the GTOD clock, we might get some inaccuracy in a single CPU
> > trace.
> >

[...]

>
> this is not a good idea. We want to fix cpu_clock(), not work around any
> deficiencies it might have.

cpu_clock currently is "sched_clock" when the
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK is not set. Which is done via configuration,
and I noticed is set on my boxes with a stable TSC??

Perhaps we need to make cpu_clock change dynamically when an unstable
sched_clock is detected.

Even in this case, forcing the tracers that are single CPU to use a clock
source that modifies itself to try to look stable across CPUs still seems
wrong to me.  The goal of looking stable across CPUs will always be at odds
with the irqsoff tracer that does not care about other CPUS but cares
tremendously about accurate latencies.

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