linux-kernel - Re: [PATCH 3/5] lockstat: core infrastructure

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 01 Jun 2007 12:30:36 -0700
From:	Daniel Walker <dwalker@...sta.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jason Baron <jbaron@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/5] lockstat: core infrastructure

On Fri, 2007-06-01 at 20:19 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@...sta.com> wrote:
> 
> > > > > I see sched_clock() as fast first, accurate second. Whereas the 
> > > > > clocksource thing is accurate first, fast second.
> > > > 
> > > > This is true .. However, if there is a speed different it's small.
> > > 
> > > Ugh. Have you ever compared pmtimer (or even hpet) against TSC based 
> > > sched_clock()? What you write is so wrong that it's not even funny. 
> > > You keep repeating this nonsense despite having been told multiple 
> > > times that you are dead wrong.
> > 
> > Yes I have, and your right there is a difference, and a big difference 
> > .. Above I was referring only to the TSC clocksource, since that's an 
> > apples to apples comparison .. I would never compare the TSC to the 
> > acpi_pm, that's no contest ..
> 
> You still dont get it i think: in real life we end up using the TSC in 
> sched_clock() _much more often_ than we end up using the TSC for 
> clocksource! So your flawed suggestion does not fix anything, it in fact 
> introduces a really bad regression: instead of using the TSC (or 
> jiffies) we'd end up using the pmtimer or hpet for every lock operation 
> when lockstat is enabled, bringing the box to a screeching halt in 
> essence.

My position isn't that we should use the high level clocksource
interface as it is now without changes .. That's never been my position
since I've been working with it.. The high level interface will need to
evolve. 

I'm saying we should use the clocksource structure as the main hook into
the low level architecture code. 

> so what you suggest has a far worse effect on the _majority_ of systems 
> that are even interested in running lockstat, than the case you 
> mentioned that some seldom-used arch which is lazy about sched_clock() 
> falls back to jiffies granularity. It's not a big deal: the stats will 
> have the same granularity. (the op counts in lockstat will still be 
> quite useful)

My suggestion is only as good as the implementation .. Your making some
fairly sweeping assumption about how lockstat _would_ use the
clocksources in it's final form ..

So clearly lockstat has a contraint which is that it can't use slow
clocks.. 

> sched_clock() is a 'fast but occasionally inaccurate clock', while the 
> GTOD clocksource is an accurate clock (but very often slow).

I think we're just taking different perspectives .. The tsc clocksource
is just as fast as the tsc sched_clock() , you can interchange the two
without ill effects .. That's one perspective ..

You can use a yet to be written API that uses the GTOD and a
clocksource, and allows slow clocksources to be used in place of fast
ones with really bad effects, that's another perspective ..

Daniel

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