linux-kernel - Re: [PATCH] sched: Distinguish sched_wakeup event when wake up a task which did schedule out or not.

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: <53708D34.1070600@cn.fujitsu.com>
Date:	Mon, 12 May 2014 17:58:28 +0900
From:	Dongsheng Yang <yangds.fnst@...fujitsu.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Steven Rostedt <rostedt@...dmis.org>,
	Dongsheng Yang <dongsheng081251@...il.com>,
	<linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
	<bsegall@...gle.com>
Subject: Re: [PATCH] sched: Distinguish sched_wakeup event when wake up a
 task which did schedule out or not.

On 05/12/2014 03:47 PM, Peter Zijlstra wrote:
> On Sun, May 11, 2014 at 02:52:24PM -0400, Steven Rostedt wrote:
>> On Sun, 11 May 2014 18:35:31 +0200
>> Peter Zijlstra <peterz@...radead.org> wrote:
>> I believe you may be misunderstanding Dongsheng. It has nothing to do
>> with the wake condition. But the "success" is basically saying, "did I
>> move the task on to the run queue?". That's a relevant piece of
>> information that the wake up event isn't currently showing.
>>
>> Let me ask you this; with Donsheng's patch, will there ever be a
>> sched_switch event when the wakeup event sees 'false' and the
>> sched_switch event see the task with a state other than "R"? And if so,
>> how did the task doing the wakeup event, wake up that task?
> But that has nothing what so fucking ever to do with 'success'. Reusing
> that trace argument for something entirely different is just retarded.

Hi Peter,

we need to distinguish the true_wakeup and false_wakeup because
we want to know the timestamp when a task moved into runqueue.
Then we can calculate the latency time in perf sched latency command.

Without this patch, we will always get wakeup events with .success==true,
and we can not get the accurate time of task on run queue waiting for
cpu.

In original design of sched:sched_wakeup, actually was what I described
in commit message, .success==true means task go into run queue. And
perf-sched.c does only care events with this type:

         /* Note for later, it may be interesting to observe the failing 
cases */
         if (!success)
                 return 0;

And if scheduler raise an wakeup event with .success=true in 
ttwu_do_wakeup(),
perf sched latency will find the last state of this task is not out of 
run queue. Then
it will be confused and print a bug message for it.

# perf sched latency|tail
   bash:3498             |      0.785 ms |        1 | avg:    0.000 ms | 
max:    0.000 ms | max at:  0.000000 s
   bash:3600             |      0.522 ms |        1 | avg:    0.000 ms | 
max:    0.000 ms | max at:  0.000000 s
   bash:3570             |      0.295 ms |        1 | avg:    0.000 ms | 
max:    0.000 ms | max at:  0.000000 s
   bash:3581             |      0.288 ms |        1 | avg:    0.000 ms | 
max:    0.000 ms | max at:  0.000000 s
   bash:3594             |      0.286 ms |        1 | avg:    0.000 ms | 
max:    0.000 ms | max at:  0.000000 s
  -----------------------------------------------------------------------------------------
   TOTAL:                |   2768.420 ms |    17331 |
  ---------------------------------------------------
   INFO: 0.482% state machine bugs (82 out of 17008)



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