linux-kernel - Re: Plumbers: Tweaking scheduler policy micro-conf RFP

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]

Date:	Tue, 15 May 2012 12:17:02 +0300
From:	Pantelis Antoniou <pantelis.antoniou@...il.com>
To:	Vincent Guittot <vincent.guittot@...aro.org>
Cc:	mou Chen <hi3766691@...il.com>, 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 May 15, 2012, at 12:07 PM, Vincent Guittot wrote:

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

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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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