linux-kernel - Re: [RFC PATCH] sched: Fix 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]

Message-ID: <2005583386.6872.1433829181079.JavaMail.zimbra@efficios.com>
Date:	Tue, 9 Jun 2015 05:53:01 +0000 (UTC)
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>, rostedt <rostedt@...dmis.org>,
	Francis Giraldeau <francis.giraldeau@...il.com>
Subject: Re: [RFC PATCH] sched: Fix sched_wakeup tracepoint

----- On Jun 8, 2015, at 8:55 AM, Peter Zijlstra peterz@...radead.org wrote:

> On Fri, 2015-06-05 at 13:23 +0000, Mathieu Desnoyers wrote:
>> sched_wakeup: when try_to_wake_up{,_local} is called in the waker.
>> sched_activate_task: when the wakee is marked runnable.
>> sched_switch: when scheduling actually happens.
>> 
>> We can then calculate wakeup latency as
>> 
>>   time@...ed_activate - time@...ed_wakeup
> 
> One more thing, I think I would disagree with this. I would suggest
> never to use the 'wakeup' (or 'waking' in my proposal) for timing. I
> would suggest to use your interrupt tracepoint (or whatever else causes
> wakeup to be called for this).

The nice thing about the 'waking' tracepoint is that there is only
one to trace if we care about wakeup latency, and it only executes when
there is an actual wake up performed.

If we do care about more timing precision of the wakeup latency, we might
indeed want to trace both 'waking' and whatever calls it (interrupt, set
of system calls, etc.)

An instrumentation of 'waking' however seems like a good approximation
of the moment where the wakeup is requested by the waker. Especially
if we compute critical path of a computation: then we already account
for process runtime within the waker before the 'woken' event. So we
don't really care about the extra precision that we would get by tracing
the exact syscall entry point.

In all cases we need the wakee PID awakened by 'waking', which is
unavailable unless we add the 'waking' event.

> 
> The wakeup times should be measured in tasktime -- of course, if
> interrupts/preemption are disabled then tasktime == walltime.
> 
> The scheduling bit OTOH always needs to be measured in walltime, and is
> most affected by the presence of other tasks on the system.
> 
> This too is why I'm not sure it makes sense to combine the two into a
> single measurement. They should be measured in different time domains.

That's a very good point! Agreed.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
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/