All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pantelis Antoniou <pantelis.antoniou@gmail.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: mou Chen <hi3766691@gmail.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	torvalds@linux-foundation.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: Plumbers: Tweaking scheduler policy micro-conf RFP
Date: Tue, 15 May 2012 12:17:02 +0300	[thread overview]
Message-ID: <833A8DB8-1AB4-45E4-8D44-14A0D782807D@gmail.com> (raw)
In-Reply-To: <CAKfTPtBhPpQyr1qugbMzq2nENh+zBT+zx_nWQpQ9NPbF=+ppcQ@mail.gmail.com>


On May 15, 2012, at 12:07 PM, Vincent Guittot wrote:

> On 15 May 2012 10:34, mou Chen <hi3766691@gmail.com> wrote:
>> Hi Vincent
>> 
>> There is no necessary to change the scheduling policy for for a
>> SPECIFIC work. In case changing the scheduling policy just for this
>> reason will drop the total performance at all. People know that
>> desktop scheduler is for interactivity and server scheduler is for
>> throughput and we are just designing a scheduler for these 2 groups of
>> task.
> 
> Hi Chen,
> 
> First of all, I'm not sure that limiting the scheduling policy to
> server and desktop mode is the right solution because Linux is used in
> much more system like the embedded one.
> 
> Then, some weaknesses have been point out around the sched_mc and its
> power saving policy and IIRC Peter was close to remove the sched_mc
> stuff: http://thread.gmane.org/gmane.linux.kernel/1236846. It sounds
> like the sched_mc should be removed, replace or at least rework to
> have something smarter which takes into account more inputs than just
> cluster or hyper threading links between cores which seems to be no
> more sufficient.
> 
> So LPC would be a good place to discuss this point
> 
> Regards,
> Vincent
> 

Hi Vincent

IMO this whole idea about 'server' or 'desktop' schedulers is bunk.

There should only be a single scheduler, but it should be flexible
enough to cater to the needs of quite different classes of hardware,
and their specific workload requirements.

I feel that we're in the birthing pains period of where what used
to be a simple goal (perform as much work as possible in the minimum
amount of time) for the scheduler, turns into something more complex
(perform as much work as possible while staying within this power &
thermal envelope).

The LPC should be an excellent place to discuss how we can achieve this.

Regards

-- Pantelis

PS. Or have lots of beer crying over it...


>> 
>> All right you may not agree with me at all. However, changing the
>> policy for a SPECIFIC work is unnecessary. Or it is more better to
>> share about "how to make a scheduler for yourselves" with people who
>> don't know how to write a scheduler. :-)
>> 
>>                                                      Chen
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2012-05-15  9:17 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-11 16:16 Plumbers: Tweaking scheduler policy micro-conf RFP Vincent Guittot
2012-05-11 16:26 ` Steven Rostedt
2012-05-11 16:38   ` Vincent Guittot
2012-05-15  8:41     ` Juri Lelli
2012-05-15  0:53 ` Paul E. McKenney
2012-05-15  8:02 ` Vincent Guittot
2012-05-15  8:34   ` mou Chen
2012-05-15  9:07     ` Vincent Guittot
2012-05-15  9:17       ` Pantelis Antoniou [this message]
2012-05-15 10:28         ` Peter Zijlstra
2012-05-15 11:35           ` Pantelis Antoniou
2012-05-15 11:58             ` Peter Zijlstra
2012-05-15 12:32               ` Pantelis Antoniou
2012-05-15 12:59                 ` Peter Zijlstra
2012-05-19 14:58               ` Luming Yu
2012-05-15 20:26             ` valdis.kletnieks
2012-05-15 20:33               ` Peter Zijlstra
2012-05-16 12:08               ` Pantelis Antoniou
2012-05-15 12:23   ` Peter Zijlstra
2012-05-15 12:27     ` Peter Zijlstra
2012-05-15 12:57     ` Vincent Guittot
2012-05-15 13:00       ` Peter Zijlstra
2012-05-15 15:05         ` Vincent Guittot
2012-05-15 15:19           ` Paul E. McKenney
2012-05-15 15:27             ` Vincent Guittot
2012-05-15 15:35           ` Peter Zijlstra
2012-05-15 15:45             ` Peter Zijlstra
2012-05-16 18:30             ` Peter Zijlstra
2012-05-19 17:08               ` Linus Torvalds
2012-05-19 22:55                 ` Peter Zijlstra
2012-05-22  2:38                   ` Chen
2012-05-22  5:14                     ` Chen
2012-05-30  7:20                       ` Ingo Molnar
2012-05-23 15:03                     ` Ingo Molnar
2012-05-23 15:43                       ` Joe Perches
2012-05-23 15:50                         ` Ingo Molnar
2012-05-23 15:56                           ` Joe Perches
2012-05-23 15:59                             ` Ingo Molnar
2012-05-29 18:17                           ` [PATCH] printk: Shrink printk_sched buffer size, eliminate it when !CONFIG_PRINTK Joe Perches
2012-06-05 16:04                             ` Joe Perches
2012-06-06  7:25                               ` Ingo Molnar
2012-06-06  7:33                             ` Ingo Molnar
2012-06-06  7:42                               ` Joe Perches
2012-05-19 23:13                 ` Plumbers: Tweaking scheduler policy micro-conf RFP Peter Zijlstra
2012-05-19 23:22                 ` Peter Zijlstra
2012-05-21  7:16                   ` Ingo Molnar
2012-05-21 16:56                     ` Linus Torvalds
2012-05-16 18:49             ` Vaidyanathan Srinivasan
2012-05-16 19:40               ` Peter Zijlstra
2012-05-16 21:20             ` Vincent Guittot
     [not found]             ` <20120518161817.GE18312@e103034-lin.cambridge.arm.com>
2012-05-18 16:24               ` Morten Rasmussen
2012-05-18 16:39                 ` Peter Zijlstra
2012-05-18 16:46                 ` Pantelis Antoniou
2012-05-15 16:30           ` Vaidyanathan Srinivasan
2012-05-15 18:13             ` Vincent Guittot

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=833A8DB8-1AB4-45E4-8D44-14A0D782807D@gmail.com \
    --to=pantelis.antoniou@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=hi3766691@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vincent.guittot@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.