login
Header Space

 
 

Linux: PlugSched, Pluggable CPU Schedulers

July 18, 2007 - 4:27am
Submitted by Jeremy on July 18, 2007 - 4:27am.
Linux news

Updating the pluggable scheduler patches for the 2.6.22 kernel, Peter Williams noted, "probably the last one now that CFS is in the main line". CFS author Ingo Molnar asked, "why is CFS in mainline a problem? The CFS merge should make the life of development/test patches like plugsched conceptually easier." Peter explained, "it means a major rewrite of the plugsched interface and I'm not sure that it's worth it (if CFS works well). However, note that I did say probably not definitely :-). I'll play with it and see what happens."

Ingo went on to suggest, "most of the schedulers in plugsched should be readily adaptable to the modular scheduling-policy scheme of the upstream scheduler. I'm sure there will be some minor issues as isolation of the modules is not enforced right now - and i'd be happy to review (and potentially apply) common-sense patches that improve the framework." Peter wasn't entirely convinced, but added, "I don't feel like converting staircase and nicksched as I have no real interest in them. Perhaps I'll just create the interface and some schedulers based on my own ideas and let others such as Con and Nick add schedulers if they're still that way inclined." In response to Ingo's offer to review the work he noted, "thanks for the offer of support (it may sway my decision)".


From:	Peter Williams [email blocked]
To:	Linux Kernel Mailing List [email blocked]
Subject: [ANNOUNCE][RFC] PlugSched-6.5.1 for  2.6.22
Date:	Wed, 11 Jul 2007 15:44:25 +1000

Probably the last one now that CFS is in the main line :-(.

A patch for 2.6.22 is available at:

<http://downloads.sourceforge.net/cpuse/plugsched-6.5.1-for-2.6.22.patch;

Very Brief Documentation:

You can select a default scheduler at kernel build time.  If you wish to
boot with a scheduler other than the default it can be selected at boot
time by adding:

cpusched=<scheduler>

to the boot command line where <scheduler> is one of: ingosched,
ingo_ll, nicksched, staircase, spa_no_frills, spa_ws, spa_svr, spa_ebs
or zaphod.  If you don't change the default when you build the kernel
the default scheduler will be ingosched (which is the normal scheduler).

The scheduler in force on a running system can be determined by the
contents of:

/proc/scheduler

Control parameters for the scheduler can be read/set via files in:

/sys/cpusched/<scheduler>/

Peter
-- 
Peter Williams [email blocked]

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce


From: Ingo Molnar [email blocked] To: Peter Williams [email blocked] Cc: Linux Kernel Mailing List [email blocked] Subject: Re: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22 Date: Mon, 16 Jul 2007 10:20:25 +0200 * Peter Williams [email blocked] wrote: > Probably the last one now that CFS is in the main line :-(. hm, why is CFS in mainline a problem? The CFS merge should make the life of development/test patches like plugsched conceptually easier. (it will certainly cause a lot of churn, but that's for the better i think.) Most of the schedulers in plugsched should be readily adaptable to the modular scheduling-policy scheme of the upstream scheduler. I'm sure there will be some minor issues as isolation of the modules is not enforced right now - and i'd be happy to review (and potentially apply) common-sense patches that improve the framework. Ingo
From: Peter Williams [email blocked] To: Ingo Molnar [email blocked] CC: Linux Kernel Mailing List [email blocked] Subject: Re: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22 Date: Tue, 17 Jul 2007 10:09:35 +1000 Ingo Molnar wrote: > * Peter Williams [email blocked] wrote: > >> Probably the last one now that CFS is in the main line :-(. > > hm, why is CFS in mainline a problem? It means a major rewrite of the plugsched interface and I'm not sure that it's worth it (if CFS works well). However, note that I did say probably not definitely :-). I'll play with it and see what happens. > The CFS merge should make the life > of development/test patches like plugsched conceptually easier. (it will > certainly cause a lot of churn, but that's for the better i think.) I don't think that is necessarily the case. > > Most of the schedulers in plugsched should be readily adaptable to the > modular scheduling-policy scheme of the upstream scheduler. I don't think that this necessarily true. Ingosched and ingo_ll are definitely out and I don't feel like converting staircase and nicksched as I have no real interest in them. Perhaps I'll just create the interface and some schedulers based on my own ideas and let others such as Con and Nick add schedulers if they're still that way inclined. > I'm sure > there will be some minor issues as isolation of the modules is not > enforced right now - and i'd be happy to review (and potentially apply) > common-sense patches that improve the framework. Thanks for the offer of support (it may sway my decision), Peter -- Peter Williams [email blocked] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce



Related Links:

Linux 2007 <-> SunOS 1994? ;-)

July 18, 2007 - 5:00am

Wow, Linux just got another feature that Solaris had in 1994. ;->

That didn't help Solaris

July 18, 2007 - 6:27am
Anonymous (not verified)

That didn't help Solaris much all these years.

That's true, because hype

July 18, 2007 - 8:01am
Anonymous (not verified)

That's true, because hype isn't about competition, it's about lies!

And who would know better

July 18, 2007 - 10:43am
Anonymous (not verified)

And who would know better than the makers of the POSs called Java and SunOS?

Could you provide an example

July 18, 2007 - 4:40pm

Could you provide an example of Sun lying about SunOS?

Plugsched is nothing new

July 18, 2007 - 10:31am

Plugsched is nothing new, its been around for a long time. I'm going to assume you read the title of the article and stopped there, because this is quite clearly not an announcement of new functionality.

Sorry, in the real world

July 18, 2007 - 2:53pm

Sorry, in the real world functionality accessible only as a proof of concept, experimental patch doesn't really count. What counts are features that are distributed, ready to use.

Ok, in this way Linux still does not have pluggable schedulers. Oh well.

Why Pluggable CPU Schedulers?

July 19, 2007 - 1:52pm
Fred Flinta (not verified)

Why have Pluggable CPU Schedulers?
Who would want it anyway?

I am a noob, but really, I don't see whats good about it for Linux users, I only see it is usable for CPU scheduler developers.

Wouldn't it be better to just have a good CPU scheduler?

Also, does having it pluggable, reduce its performance or cause some bloat?

Choice is good

July 21, 2007 - 10:59am

It's a benefit if for no other reason than choice is good. CFS may be the best "general purpose" scheduler, but that doesn't necessarily make it ideal for all workloads.

Similarly, "TCP Reno" and "TCP Vegas" (and now "TCP BIC") are good general purpose congestion control algorithms, but I have a server that I want to have very low network priority so I set it to "TCP LP" and I have another server that primarily hits wireless clients so I have that set to "TCP Westwood".

The ability to have a pluggable anything is a benefit because it can make hard things easy (if someone else already did the work) or at least possible because there's an infrastructure to tailor it to your individual needs.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary