linux-kernel - Re: [ANNOUNCE][RFC] PlugSched-6.4 for 2.6.18-rc2

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, 25 Jul 2006 15:44:35 +1000
From:	Peter Williams <pwil3058@...pond.net.au>
To:	Al Boldi <a1426z@...ab.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE][RFC] PlugSched-6.4 for 2.6.18-rc2

Al Boldi wrote:
> Peter Williams wrote:
>> Al Boldi wrote:
>>> Peter Williams wrote:
>>>> This version removes the hard/soft CPU rate caps from the SPA
>>>> schedulers.
>>>>
>>>> A patch for 2.6.18-rc2 is available at:
>>>>
>>>> <http://prdownloads.sourceforge.net/cpuse/plugsched-6.4-for-2.6.18-rc2.
>>>> pat ch?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>
>>> Any reason dynsched couldn't be merged with plugsched?
>> None that I know of (but I'm not familiar with dynsched).  Patches to
>> add it to the mix would be accepted and once in I would try to keep it
>> in step with kernel changes.
> 
> I thought dynsched patches against plugsched, what else is needed?
>

Hopefully, nothing but it may be necessary to modify the plugsched 
interface if dynsched can't be implemented against it "as is".  E.g. 
both staircase and nicksched needed changes to what was required for 
ingosched and the SPA schedulers.

>>>> 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
>>> It may be really great, to allow schedulers perPid parent, thus allowing
>>> the stacking of different scheduler semantics.  This could aid
>>> flexibility a lot.
>> I'm don't understand what you mean here.  Could you elaborate?
> 
> i.e:  Boot the kernel with spa_no_frills, then start X with spa_ws.

It's probably not a good idea to have different schedulers managing the 
same resource.  The way to do different scheduling per process is to use 
the scheduling policy mechanism i.e. SCHED_FIFO, SCHED_RR, etc. 
(possibly extended) within each scheduler.  On the other hand, on an SMP 
system, having a different scheduler on each run queue (or sub set of 
queues) might be interesting :-).  The schedulers would probably have to 
have a common idea of how the run queue works though and this would 
restrict the choice of schedulers.

I have no intentions (at the moment) of going down this path myself.

However, I am thinking about making it possible to switch between the 
various SPA schedulers on a running system.  A extension to this could 
be to attempt automatic selection of which scheduler to use possibly 
based on which users are logged in.

Peter
-- 
Peter Williams                                   pwil3058@...pond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce
-
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/