linux-kernel - Re: perf,tools: Remove usage of trace_sched

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:	Tue, 13 May 2014 19:30:32 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Dongsheng Yang <yangds.fnst@...fujitsu.com>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Jiri Olsa <jolsa@...nel.org>, linux-kernel@...r.kernel.org,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: perf,tools: Remove usage of trace_sched_wakeup(.success)

On Tue, May 13, 2014 at 07:14:36PM +0200, Ingo Molnar wrote:
> 
> * Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > On Tue, May 13, 2014 at 03:34:32PM +0900, Dongsheng Yang wrote:
> > > On 05/13/2014 04:22 PM, Ingo Molnar wrote:
> > > >* Peter Zijlstra <peterz@...radead.org> wrote:
> > > >
> > > >>trace_sched_wakeup(.success) is a dead argument and has been for ages,
> > > >Always 0, or random value?
> > > 
> > > Hi Ingo,
> > > 
> > > It is always 1 currently.
> > > 
> > > Peter believe that .success is not useful and I pointed that perf 
> > > sched latency is using it now. Then he post this patch to remove 
> > > the usage here.
> > > 
> > > Please go to the following link for more about this issue.
> > 
> > It is _not_ usable. You're proposing to abuse the existing 
> > parameter. A wakeup doing an enqueue or not has nothing 
> > _WHAT_SO_EVER_ to do with success.
> > 
> > Now what I think you wanted to do is make it easier to match 
> > trace_sched_switch() statements with trace_sched_wakeup() 
> > statements. And since you only get the trace_sched_switch() on 
> > dequeue, you want to know which trace_sched_wakeup() calls did an 
> > enqueue.
> > 
> > But that's completely and utterly unrelated to success.
> 
> So I always considered it 'the enqueue was successful' - that's I 
> think why I added it to 'perf sched' originally - to be able to trace 
> wakeups from originator to target.

So back when it still sometimes returned 0 it was the try_to_wake_up()
return value, it still is, except when we re factored ttwu we moved the
tracepoint such that its not on the 0 return path.

I would've removed it then, except I couldn't because some crap
userspace was using it -- and that's the only reason its still in there,
its been a pointless rudiment for years.

Anyway, the return value is true if it (potentially) did an actual
wakeup, and that is unrelated to having done an enqueue.

And in general you want wakeups to happen before we do the dequeue, as
the enqueue-less wakeups are _way_ faster. I've tried optimistic
yield(), but since not all schedule() site can deal with spurious
wakeups that fell flat :/
--
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/