This version contains a new scheduler, spa_svr, which is a minor
extension of spa_no_frills intended for use on servers. It makes no
attempt to improve interactive responsiveness but includes a simplified
version of the throughput bonus mechanism found in Zaphod. This
mechanism attempts to minimize the time tasks spend on run queues
waiting for CPU access when the system is moderately loaded by giving
tasks temporary priority bonuses based on the relationship between the
recent average time spent on run queues and on a cpu per cycle.
(Although it's effectiveness tends to disappear when the system is fully
loaded, it is still useful as considerable delay can be seen on systems
with quite low average loads due to lack of serendipity.)
A patch for 2.6.14-rc4 is available at:
<http://prdownloads.sourceforge.net/cpuse/plugsched-6.1.3-for-2.6.14-rc4.patch?download>
and a patch to upgrade the 6.1.2 version for 2.6.13 to 6.1.3 is
available at:
<http://prdownloads.sourceforge.net/cpuse/plugsched-6.1.2-to-6.1.3-for-2.6.13.patch?download>
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,
nicksched, staircase, spa_no_frills, spa_ws, spa_svr 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 protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
Peter Williams wrote:
> This version contains a new scheduler, spa_svr, which is a minor
> extension of spa_no_frills intended for use on servers. It makes no
> attempt to improve interactive responsiveness but includes a simplified
> version of the throughput bonus mechanism found in Zaphod. This
> mechanism attempts to minimize the time tasks spend on run queues
> waiting for CPU access when the system is moderately loaded by giving
> tasks temporary priority bonuses based on the relationship between the
> recent average time spent on run queues and on a cpu per cycle.
> (Although it's effectiveness tends to disappear when the system is fully
> loaded, it is still useful as considerable delay can be seen on systems
> with quite low average loads due to lack of serendipity.)
>
> A patch for 2.6.14-rc4 is available at:
>
> <http://prdownloads.sourceforge.net/cpuse/plugsched-6.1.3-for-2.6.14-rc4.patch?download>
>
>
> and a patch to upgrade the 6.1.2 version for 2.6.13 to 6.1.3 is
> available at:
>
> <http://prdownloads.sourceforge.net/cpuse/plugsched-6.1.2-to-6.1.3-for-2.6.13.patch?download>
>
>
> 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,
> nicksched, staircase, spa_no_frills, spa_ws, spa_svr 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
A patch for the 2.6.14 official release kernel is now available at:
<http://prdownloads.sourceforge.net/cpuse/plugsched-6.1.3-for-2.6.14.patch?download>
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
Peter Williams wrote:
> This version contains a new scheduler, spa_svr, which is a minor
> extension of spa_no_frills intended for use on servers. It makes no
> attempt to improve interactive responsiveness but includes a simplified
> version of the throughput bonus mechanism found in Zaphod. This
> mechanism attempts to minimize the time tasks spend on run queues
> waiting for CPU access when the system is moderately loaded by giving
> tasks temporary priority bonuses based on the relationship between the
> recent average time spent on run queues and on a cpu per cycle.
> (Although it's effectiveness tends to disappear when the system is fully
> loaded, it is still useful as considerable delay can be seen on systems
> with quite low average loads due to lack of serendipity.)
>
> A patch for 2.6.14-rc4 is available at:
>
> <http://prdownloads.sourceforge.net/cpuse/plugsched-6.1.3-for-2.6.14-rc4.patch?download>
>
>
> and a patch to upgrade the 6.1.2 version for 2.6.13 to 6.1.3 is
> available at:
>
> <http://prdownloads.sourceforge.net/cpuse/plugsched-6.1.2-to-6.1.3-for-2.6.13.patch?download>
>
>
> 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,
> nicksched, staircase, spa_no_frills, spa_ws, spa_svr 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
A patch for the 2.6.14-mm1 kernel is now available at:
<http://prdownloads.sourceforge.net/cpuse/plugsched-6.1.3-for-2.6.14-mm1.patch?download>
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
Hi Peter et al
Here is an update to bring plugsched in line with the current version of
staircase.
Cheers,
Con
Hi Peter et al
I find the Kconfig menu layout a little confusing and suggest the following
patch.
Cheers,
Con
On Fri, 11 Nov 2005 02:05 pm, Con Kolivas wrote:
> Hi Peter et al
>
> I find the Kconfig menu layout a little confusing and suggest the following
> patch.
Actually I changed my mind about the first part. If you deselect plugsched you
need some way of selecting the default scheduler, sorry. I'll spin up a patch
with just the spa submenu.
Cheers,
Con
Here's a respin just changing the spa menu.
Cheers,
Con
Con Kolivas wrote:
> Here's a respin just changing the spa menu.
>
While agreeing that PlugSched's configuration needs overhaul I don't
think this is it as it just makes things more confusing. I'll put
fixing the configuration code on my list of things to do. They main
changes I see as necessary are:
1. Make the ability to select which schedulers are built in independent
of EMBEDDED.
2. Only offer builtin schedulers as choice for the default scheduler.
3. Only build in ingosched if PLUGSCHED is not configured.
I'll try to get this change done next week.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
Con Kolivas wrote:
> Hi Peter et al
>
> Here is an update to bring plugsched in line with the current version of
> staircase.
>
Applied to my sources and will be in the next release (probably
tomorrow) after some more testing.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
On Sun, 13 Nov 2005 12:34, Peter Williams wrote:
> Con Kolivas wrote:
> > Here's a respin just changing the spa menu.
>
> While agreeing that PlugSched's configuration needs overhaul I don't
> think this is it as it just makes things more confusing. I'll put
> fixing the configuration code on my list of things to do. They main
> changes I see as necessary are:
>
> 1. Make the ability to select which schedulers are built in independent
> of EMBEDDED.
> 2. Only offer builtin schedulers as choice for the default scheduler.
> 3. Only build in ingosched if PLUGSCHED is not configured.
I disagree with 3. Surely people might want to build in only one scheduler
that is not ingosched without other choices.
Cheers,
Con
Con Kolivas wrote:
> On Sun, 13 Nov 2005 12:34, Peter Williams wrote:
>
>>Con Kolivas wrote:
>>
>>>Here's a respin just changing the spa menu.
>>
>>While agreeing that PlugSched's configuration needs overhaul I don't
>>think this is it as it just makes things more confusing. I'll put
>>fixing the configuration code on my list of things to do. They main
>>changes I see as necessary are:
>>
>>1. Make the ability to select which schedulers are built in independent
>>of EMBEDDED.
>>2. Only offer builtin schedulers as choice for the default scheduler.
>>3. Only build in ingosched if PLUGSCHED is not configured.
>
>
> I disagree with 3. Surely people might want to build in only one scheduler
> that is not ingosched without other choices.
Yes, and they would be able to do that by selecting PLUGSCHED and then
selecting only the scheduler that they want. But this then leads to the
observation that PLUGSCHED is probably makes things unnecessarily
complex and all that is required is a means to select the schedulers to
be built in and a choice of default (much like for the IO schedulers)?
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
On Sun, 13 Nov 2005 16:22, Peter Williams wrote:
> Con Kolivas wrote:
> > On Sun, 13 Nov 2005 12:34, Peter Williams wrote:
> >>1. Make the ability to select which schedulers are built in independent
> >>of EMBEDDED.
> >>2. Only offer builtin schedulers as choice for the default scheduler.
> >>3. Only build in ingosched if PLUGSCHED is not configured.
> >
> > I disagree with 3. Surely people might want to build in only one
> > scheduler that is not ingosched without other choices.
>
> Yes, and they would be able to do that by selecting PLUGSCHED and then
> selecting only the scheduler that they want. But this then leads to the
> observation that PLUGSCHED is probably makes things unnecessarily
> complex and all that is required is a means to select the schedulers to
> be built in and a choice of default (much like for the IO schedulers)?
Indeed it may be better to remove the "plugsched" option entirely. Once
patched in it's not like you are building the kernel without the plugsched
infrastructure. Provided each extra scheduler does not increase the kernel
size too much (and a test build with/without all schedulers should tell you
that), it may be best to just have the scheduler choice in the top menu and
only expose the "schedulers to build in" under embedded.
Of course if adding all the schedulers adds a lot of size to the kernel then
it would be best to retain the "build support for multiple cpu schedulers"
and default it to off. Do you have a quick comparison of build sizes
with/without the various cpu schedulers? Last time I checked, staircase was a
few hundred bytes larger than mainline despite being 200 lines of code less,
probably due to its largely inline nature.
Cheers,
Con
Con Kolivas wrote:
> On Sun, 13 Nov 2005 16:22, Peter Williams wrote:
>
>>Con Kolivas wrote:
>>
>>>On Sun, 13 Nov 2005 12:34, Peter Williams wrote:
>>>
>>>>1. Make the ability to select which schedulers are built in independent
>>>>of EMBEDDED.
>>>>2. Only offer builtin schedulers as choice for the default scheduler.
>>>>3. Only build in ingosched if PLUGSCHED is not configured.
>>>
>>>I disagree with 3. Surely people might want to build in only one
>>>scheduler that is not ingosched without other choices.
>>
>>Yes, and they would be able to do that by selecting PLUGSCHED and then
>>selecting only the scheduler that they want. But this then leads to the
>>observation that PLUGSCHED is probably makes things unnecessarily
>>complex and all that is required is a means to select the schedulers to
>>be built in and a choice of default (much like for the IO schedulers)?
>
>
> Indeed it may be better to remove the "plugsched" option entirely. Once
> patched in it's not like you are building the kernel without the plugsched
> infrastructure. Provided each extra scheduler does not increase the kernel
> size too much (and a test build with/without all schedulers should tell you
> that), it may be best to just have the scheduler choice in the top menu and
> only expose the "schedulers to build in" under embedded.
I can't see why this should be restricted to embedded systems?
>
> Of course if adding all the schedulers adds a lot of size to the kernel then
> it would be best to retain the "build support for multiple cpu schedulers"
> and default it to off.
You achieve the same just by selecting only one scheduler. PLUGSCHED
(currently) doesn't directly control the inclusion of any code and it's
only effect is by controlling which schedulers are included. It may be
possible to change this so that the checking of the boot time scheduler
selection code is excluded.
> Do you have a quick comparison of build sizes
> with/without the various cpu schedulers?
I'll check. I'll also see how much difference the boot time selection
code adds but I doubt whether it's very much.
> Last time I checked, staircase was a
> few hundred bytes larger than mainline despite being 200 lines of code less,
> probably due to its largely inline nature.
Each scheduler costs about 10kB on average. Mine are the largest :-(
(too many features including making extra stats available via /proc?)
and I should look at improving that.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
On Sun, 13 Nov 2005 20:10, Peter Williams wrote:
> Con Kolivas wrote:
> > On Sun, 13 Nov 2005 16:22, Peter Williams wrote:
> >>Con Kolivas wrote:
> >>>On Sun, 13 Nov 2005 12:34, Peter Williams wrote:
> >>>>1. Make the ability to select which schedulers are built in independent
> >>>>of EMBEDDED.
> >>>>2. Only offer builtin schedulers as choice for the default scheduler.
> >>>>3. Only build in ingosched if PLUGSCHED is not configured.
> >>>
> >>>I disagree with 3. Surely people might want to build in only one
> >>>scheduler that is not ingosched without other choices.
> >>
> >>Yes, and they would be able to do that by selecting PLUGSCHED and then
> >>selecting only the scheduler that they want. But this then leads to the
> >>observation that PLUGSCHED is probably makes things unnecessarily
> >>complex and all that is required is a means to select the schedulers to
> >>be built in and a choice of default (much like for the IO schedulers)?
> >
> > Indeed it may be better to remove the "plugsched" option entirely. Once
> > patched in it's not like you are building the kernel without the
> > plugsched infrastructure. Provided each extra scheduler does not increase
> > the kernel size too much (and a test build with/without all schedulers
> > should tell you that), it may be best to just have the scheduler choice
> > in the top menu and only expose the "schedulers to build in" under
> > embedded.
>
> I can't see why this should be restricted to embedded systems?
It's just convention that size options go in there; it's not really just for
embedded systems.
Cheers,
Con
Con Kolivas wrote:
> On Sun, 13 Nov 2005 20:10, Peter Williams wrote:
>
>>Con Kolivas wrote:
>>
>>>On Sun, 13 Nov 2005 16:22, Peter Williams wrote:
>>>
>>>>Con Kolivas wrote:
>>>>
>>>>>On Sun, 13 Nov 2005 12:34, Peter Williams wrote:
>>>>>
>>>>>>1. Make the ability to select which schedulers are built in independent
>>>>>>of EMBEDDED.
>>>>>>2. Only offer builtin schedulers as choice for the default scheduler.
>>>>>>3. Only build in ingosched if PLUGSCHED is not configured.
>>>>>
>>>>>I disagree with 3. Surely people might want to build in only one
>>>>>scheduler that is not ingosched without other choices.
>>>>
>>>>Yes, and they would be able to do that by selecting PLUGSCHED and then
>>>>selecting only the scheduler that they want. But this then leads to the
>>>>observation that PLUGSCHED is probably makes things unnecessarily
>>>>complex and all that is required is a means to select the schedulers to
>>>>be built in and a choice of default (much like for the IO schedulers)?
>>>
>>>Indeed it may be better to remove the "plugsched" option entirely. Once
>>>patched in it's not like you are building the kernel without the
>>>plugsched infrastructure. Provided each extra scheduler does not increase
>>>the kernel size too much (and a test build with/without all schedulers
>>>should tell you that), it may be best to just have the scheduler choice
>>>in the top menu and only expose the "schedulers to build in" under
>>>embedded.
>>
>>I can't see why this should be restricted to embedded systems?
>
>
> It's just convention that size options go in there; it's not really just for
> embedded systems.
OK. I guess I'm sometimes guilty of taking things too literally :-(
I'll read up on Kconfig again before I make any changes.
Thanks
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce