[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfTPtBhPpQyr1qugbMzq2nENh+zBT+zx_nWQpQ9NPbF=+ppcQ@mail.gmail.com>
Date: Tue, 15 May 2012 11:07:07 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: mou Chen <hi3766691@...il.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
torvalds@...ux-foundation.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: Plumbers: Tweaking scheduler policy micro-conf RFP
On 15 May 2012 10:34, mou Chen <hi3766691@...il.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
>
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists