Hi Roland,
Roland Mainz wrote:
My idea was to provide a simple, "preconfigured" tool to do this. Right
now we have more or less the following levels of "interactivity" in the
scheduler classes:
1. "RT" (realtime)
2. "IA" (interactive processes (more or less a subclass of "TS" where an
active GUI application gets a small priority boost))
3. "TS" (plain timesharing process)
... my proposal aims at creating a level below "TS" which says "... this
is a batch job which doesn't need any interactivty at all...".
"FX" is an option but only as "jack of all trades" and doesn't (AFAIK)
allow a restriction of the priority level (e.g. "...always below TS...")
Correct, it doesn't...but since TS by default uses global priorities
0-59, that would be a difficult
semantic to implement (even with a new scheduling class) without
changing TS itself.
which opens a hole for abuse if you grant every user to use the "FX"
class (or short: "FX" is too generic and doesn't give a "hint" for
users/admins/acounting that the job is a "batch job").
Additionally "FX" misses the proposed process placement optimisation,
e.g. put "BT" (batch) (and "RT" (realtime)) jobs on free CPU sockets (or
cores) if there are "idle" ones to seperate their activity from the more
(or less) interactive processes.
The policy dealing with where (on which CPUs) things run, is currently
implemented in the
dispatcher, which is scheduling class independent...but I don't think it
necessarily has to be
that way...but along with the flexibility that scheduling class specific
dispatching policy would
bring, there would probably be a good bit of complexity too. :)
I probably wouldn't have too many real cycles to pitch in, but i'd be
interested in watching
where you go here.
-Eric
----
Bye,
Roland
P.S.: AFAIK the idea isn't "new" - SysV had a "batch scheduler class",
too...
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
