Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758039AbcC2TZT (ORCPT <rfc822;w@1wt.eu>);
	Tue, 29 Mar 2016 15:25:19 -0400
Received: from smtprelay0179.hostedemail.com ([216.40.44.179]:57513 "EHLO
	smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1753553AbcC2TZO (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 29 Mar 2016 15:25:14 -0400
X-Session-Marker: 726F737465647440676F6F646D69732E6F7267
X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::,RULES_HIT:41:355:379:541:599:800:960:967:973:988:989:1260:1263:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1535:1544:1593:1594:1605:1711:1730:1747:1777:1792:2194:2198:2199:2200:2393:2525:2553:2560:2563:2682:2685:2693:2859:2892:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4605:5007:6119:6261:6671:7875:7903:8526:8599:8660:9025:9388:10004:10049:10848:10967:11026:11232:11658:11914:12043:12296:12438:12517:12519:12555:12740:13007:13148:13180:13229:13230:13439:14181:14659:14721:21080:21324:30045:30054:30056:30070:30075:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:2,LUA_SUMMARY:none
X-HE-Tag: shock56_4a7856de00537
X-Filterd-Recvd-Size: 5928
Date: Tue, 29 Mar 2016 15:25:10 -0400
From: Steven Rostedt <rostedt@goodmis.org>
To: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>, Juri Lelli <juri.lelli@arm.com>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: [PATCH V2 3/3] sched/deadline: Tracepoints for deadline
 scheduler
Message-ID: <20160329152510.3e0f0010@gandalf.local.home>
In-Reply-To: <56FAD3A6.20205@redhat.com>
References: <cover.1459182044.git.bristot@redhat.com>
	<14f6caa05f73ceba69eff035ac542cad671552b3.1459182044.git.bristot@redhat.com>
	<20160329151649.GA12845@twins.programming.kicks-ass.net>
	<56FAA8FA.5060407@redhat.com>
	<20160329131343.3b2bcf76@gandalf.local.home>
	<56FAD3A6.20205@redhat.com>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 4568
Lines: 68

On Tue, 29 Mar 2016 16:12:38 -0300
Daniel Bristot de Oliveira <bristot@redhat.com> wrote:

> On 03/29/2016 02:13 PM, Steven Rostedt wrote:
> >>           <idle>-0     [007] d..3 78377.688969: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=b next_pid=18973 next_prio=-1  
> >> >                b-18973 [007] d..3 78377.688979: sched_deadline_block: now=78377.688976271 deadline=78377.718945137 remaining_runtime=9968866
> >> >                b-18973 [007] d..3 78377.688981: sched_switch: prev_comm=b prev_pid=18973 prev_prio=-1 prev_state=S ==> next_comm=swapper/7 next_pid=0 next_prio=120  
> > Why did it go to sleep? The above is still not very useful. What do you
> > mean "blocking on a system call"?  
> 
> A task can go can to sleep in a blocking system call, like waiting
> a network packet, or any other external event.

Note, waiting for a network packet or some other external event is a
userspace call. A schedule out in 'S' state means exactly that. But
I hate the term "blocked" because that is more like waiting for
something else to finish (like blocked on a lock). In which case, if
that did happen, the state would be "D" not "S".

"S" is basically "sleeping" and it gets woken up by some other event. A
slight difference to the term "blocked".

> 
> The "block state" is a possible state of a task running in the deadline
> scheduler. It means that a task voluntarily left the processor, not
> by calling sched_yield(), but by blocking (or sleeping) waiting another
> event.
> 
> This state is described in the Figure 2 of the article "Deadline
> scheduling in the Linux kernel", available at:
> http://onlinelibrary.wiley.com/doi/10.1002/spe.2335/abstract

Bah, confusing terminology.

> 
> The block state affects the replenishment of the task, and that is why
> it is different of both yeild and throttle. If the task blocks and is
> awakened prior to the deadline, the task's runtime will not be
> replenished. On the other hand it will. For example:
> 
> Blocking, and then waking up after the deadline:
>                b-5152  [007] d..3  3983.376428: sched_deadline_replenish: comm=b pid=5152 now=3983.376425148 deadline=3983.406425148 runtime=10000000
>                b-5152  [007] d..3  3983.376515: sched_deadline_block: now=3983.376511101 deadline=3983.406425148 remaining_runtime=9909566
>                b-5152  [007] d..3  3983.376529: sched_switch: prev_comm=b prev_pid=5152 prev_prio=-1 prev_state=S ==> next_comm=swapper/7 next_pid=0 next_prio=120
> 
>           <idle>-0     [007] d.h4  3983.476592: sched_deadline_replenish: comm=b pid=5152 now=3983.476589573 deadline=3983.506589573 runtime=10000000
>           <idle>-0     [007] dNh4  3983.476596: sched_wakeup: comm=b pid=5152 prio=-1 target_cpu=007
>           <idle>-0     [007] d..3  3983.476648: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=b next_pid=5152 next_prio=-1
>                b-5152  [007] d..3  3983.476660: sched_deadline_block: now=3983.476656613 deadline=3983.506589573 remaining_runtime=9932960
>                b-5152  [007] d..3  3983.476663: sched_switch: prev_comm=b prev_pid=5152 prev_prio=-1 prev_state=S ==> next_comm=swapper/7 next_pid=0 next_prio=120
> 
> 
> Blocking, and then waking up before the deadline:
>                b-5139  [007] d..3  3964.148290: sched_deadline_replenish: comm=b pid=5139 now=3964.148285227 deadline=3964.178285227 runtime=10000000
>                b-5139  [007] d..3  3964.148396: sched_deadline_block: now=3964.148385308 deadline=3964.178285227 remaining_runtime=9895243
>                b-5139  [007] d..3  3964.148400: sched_switch: prev_comm=b prev_pid=5139 prev_prio=-1 prev_state=S ==> next_comm=swapper/7 next_pid=0 next_prio=120
> 
>           <idle>-0     [007] dNh5  3964.148411: sched_wakeup: comm=b pid=5139 prio=-1 target_cpu=007
>           <idle>-0     [007] d..3  3964.148419: sched_switch: prev_comm=swapper/7 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=b next_pid=5139 next_prio=-1
>                b-5139  [007] d..3  3964.148427: sched_deadline_block: now=3964.148426022 deadline=3964.178285227 remaining_runtime=9878164
>                b-5139  [007] d..3  3964.148429: sched_switch: prev_comm=b prev_pid=5139 prev_prio=-1 prev_state=S ==> next_comm=swapper/7 next_pid=0 next_prio=120
> 

I still fail to see the usefulness of the block tracepoint. I could
imagine that if we add the dynamic part of the sched_switch tracepoint
to include deadline and runtime, we would get the same information.

-- Steve