public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tony Lindgren <tony@atomide.com>, Mike Galbraith <efault@gmx.de>
Subject: Re: [RFC patch 1/2] sched: dynamically adapt granularity with nr_running
Date: Sun, 12 Sep 2010 11:06:32 +0200	[thread overview]
Message-ID: <1284282392.2251.81.camel@laptop> (raw)
In-Reply-To: <AANLkTi=a91QX-FLURFWNsjbCS1bDLr6GqSpC4_uzm3ta@mail.gmail.com>

On Sat, 2010-09-11 at 13:48 -0700, Linus Torvalds wrote:
> On Sat, Sep 11, 2010 at 1:36 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> >From what I can make up:
> >
> >  LAT=`cat /proc/sys/kernel/sched_latency_ns`;
> >  echo $((LAT/8)) > /proc/sys/kernel/sched_min_granularity_ns
> >
> > will give you pretty much the same result as Mathieu's patch.
> 
> Or perhaps not. The point being that Mathieu's patch seems to do this
> dynamically based on number of runnable threads per cpu. Which seems
> to be a good idea.
> 
> IOW, this part:
> 
> -       if (delta_exec < sysctl_sched_min_granularity)
> +       if (delta_exec < __sched_gran(cfs_rq->nr_running))
> 
> seems to be a rather fundamental change, and looks at least
> potentially interesting. It seems to make conceptual sense to take the
> number of running tasks into account at that point, no?

We used to have something like that a long while back, we nixed it
because of the division and replaced it with floor(__sched_gran) (ie.
the smallest value it would ever give).

Smaller values are better for latency, larger values are better for
throughput. So introducing __sched_gran() in order to provide larger
values doesn't make sense to me.

> And I don't like how you dismissed the measured latency improvement.
> And yes, I do think latency matters. A _lot_.

OK, we'll make it better and sacrifice some throughput, can do, no
problem.

> And no, I'm not saying that Mathieu's patch is necessarily good. I
> haven't tried it myself. I don't have _that_ kind of opinion. The
> opinion I do have is that I think it's sad how you dismissed things
> out of hand - and seem to _continue_ to dismiss them without
> apparently actually having looked at the patch at all.

Let me draw you a picture of what this patch looks like to me:

 * is slice length, + is period length

Patch (sched_latency = 10, sched_min_gran = 10/3)


30 |                             +
   |
   |
   |                          +
   |
   |
   |
   |
   |
   |
20 |
   |
   |
   |
   |
   |
   |
   |
   |
   |
10 |  *  +  +  +  +  +  +  +
   |
   |
   |
   |
   |     *
   |
   |        *  *              *  *  *  *  *  *
   |              *  *
   |                    *  *
0  +---------------------------------------------------------
   0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16


Normal (sched_latency = 10, sched_min_gran = 10/3)


 30 |                          +
    |
    |
    |                       +
    |
    |
    |
    |                    +
    |
    |
 20 |                 +
    |
    |
    |              +
    |
    |                                   
    |                                
    |           +                   
    |
    |           
 10 |  *  +  +  
    |
    |
    |
    |
    |     *
    |
    |        *  *  *  *  *  *  *  *  *  *  *  *  *  *
    |
    |
 0  +---------------------------------------------------------
    0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16



Normal (sched_latency = 10, sched_min_gran = 10/8)

30 |                             
   |
   |
   |                          
   |
   |
   |
   |
   |
   |
20 |
   |
   |
   |
   |
   |                                   +
   |                                +
   |                             +
   |
   |                          +
10 |  *  +  +  +  +  +  +  +
   |
   |
   |
   |
   |     *
   |
   |        *  *              
   |              *  *
   |                    *  *  *  *  *  *  *  *
0  +---------------------------------------------------------
   0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16












  reply	other threads:[~2010-09-12  9:06 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-11 17:37 [RFC patch 0/2] sched: dynamically adapt granularity with nr_running Mathieu Desnoyers
2010-09-11 17:37 ` [RFC patch 1/2] " Mathieu Desnoyers
2010-09-11 18:57   ` Peter Zijlstra
2010-09-11 19:21     ` Linus Torvalds
2010-09-11 20:36       ` Peter Zijlstra
2010-09-11 20:45         ` Peter Zijlstra
2010-09-11 20:52           ` Linus Torvalds
2010-09-12  9:07             ` Peter Zijlstra
2010-09-11 20:48         ` Linus Torvalds
2010-09-12  9:06           ` Peter Zijlstra [this message]
2010-09-12  9:14             ` Peter Zijlstra
2010-09-12 20:39               ` Mathieu Desnoyers
2010-09-13 12:54                 ` Peter Zijlstra
2010-09-12 20:34             ` Mathieu Desnoyers
2010-09-13 12:53               ` Peter Zijlstra
2010-09-13  4:35             ` Mike Galbraith
2010-09-13  8:41               ` Peter Zijlstra
2010-09-13 11:22                 ` Ingo Molnar
2010-09-13 13:52                 ` Steven Rostedt
2010-09-13 13:54                   ` Peter Zijlstra
2010-09-13 14:02                     ` Peter Zijlstra
2010-09-13 14:21                       ` Ingo Molnar
2010-09-11 20:52         ` Mathieu Desnoyers
2010-09-11 19:57     ` Mathieu Desnoyers
2010-09-12 10:41       ` Peter Zijlstra
2010-09-12 20:37         ` Mathieu Desnoyers
2010-09-13 12:53           ` Peter Zijlstra
2010-09-13 13:15             ` Peter Zijlstra
2010-09-13 13:56               ` Mathieu Desnoyers
2010-09-13 14:16                 ` Peter Zijlstra
2010-09-13 14:43                   ` Steven Rostedt
2010-09-13 15:25                     ` Mathieu Desnoyers
2010-09-13 15:39                       ` Steven Rostedt
2010-09-13 16:16                   ` [RFC PATCH] check_preempt_tick should not compare vruntime with wall time Mathieu Desnoyers
2010-09-13 16:36                     ` Linus Torvalds
2010-09-13 17:45                       ` Mathieu Desnoyers
2010-09-13 17:51                         ` Linus Torvalds
2010-09-13 18:01                           ` Mathieu Desnoyers
2010-09-13 18:10                           ` Steven Rostedt
2010-09-13 18:03                         ` Ingo Molnar
2010-09-13 18:19                           ` Mathieu Desnoyers
2010-09-13 18:23                             ` [PATCH] sched: Improve latencies under load by decreasing minimum scheduling granularity Ingo Molnar
2010-09-13 18:28                               ` Joe Perches
2010-09-13 19:44                               ` Linus Torvalds
2010-09-13 20:00                                 ` Ingo Molnar
2010-09-13 18:19                         ` [RFC PATCH] check_preempt_tick should not compare vruntime with wall time Ingo Molnar
2010-09-13 17:36                     ` Ingo Molnar
2010-09-13 17:56                       ` Mathieu Desnoyers
2010-09-14  2:10                     ` Mike Galbraith
2010-09-13 14:44                 ` [RFC patch 1/2] sched: dynamically adapt granularity with nr_running Mike Galbraith
     [not found]               ` <1284386179.10436.6.camel@marge.simson.net>
2010-09-13 15:53                 ` Peter Zijlstra
2010-09-13 18:04                   ` [RFC][PATCH] sched: Improve tick preemption Peter Zijlstra
2010-09-14  2:27                   ` [RFC patch 1/2] sched: dynamically adapt granularity with nr_running Mike Galbraith
2010-09-12  6:14   ` Ingo Molnar
2010-09-12  7:21     ` Mike Galbraith
2010-09-12 18:16       ` Mathieu Desnoyers
2010-09-13  4:13         ` Mike Galbraith
2010-09-13  6:41           ` Ingo Molnar
2010-09-13  7:08             ` Mike Galbraith
2010-09-13  7:35               ` Mike Galbraith
2010-09-13  8:35               ` Peter Zijlstra
2010-09-13  9:16                 ` Mike Galbraith
2010-09-13  9:37                   ` Peter Zijlstra
2010-09-13  9:50                     ` Mike Galbraith
2010-09-13  9:55                       ` Peter Zijlstra
2010-09-13 10:06                         ` Mike Galbraith
2010-09-13 10:45                         ` Peter Zijlstra
2010-09-13 11:43                           ` Peter Zijlstra
2010-09-13 11:49                             ` Peter Zijlstra
2010-09-13 12:32                             ` Mike Galbraith
2010-09-13 20:19             ` Mathieu Desnoyers
2010-09-13 20:56               ` Mathieu Desnoyers
2010-09-12 18:13     ` Mathieu Desnoyers
2010-09-12 23:44       ` Mathieu Desnoyers
2010-09-11 17:37 ` [RFC patch 2/2] sched: sleepers coarse granularity on wakeup Mathieu Desnoyers
2010-09-12 12:44 ` [RFC patch 0/2] sched: dynamically adapt granularity with nr_running Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1284282392.2251.81.camel@laptop \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tony@atomide.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox