Re: is RSDL an "unfair" scheduler too?

From: Radoslaw Szkodzinski
Date: Mon Mar 19 2007 - 09:27:44 EST


On 3/19/07, David Schwartz <davids@xxxxxxxxxxxxx> wrote:

> I didn't suggest adding any unfairness! I suggested being fair by
> user/job/process instead of being fair by thread (which is actually
> unfair as it favors multi threaded processes over single threaded
> processes).

Wouldn't that be unfair because it favors multi-user approaches over
single-user approaches with the same number of processes?

Not necessarily. Use GID rotations too.
And if you can't assign these properly, it's your own/your distro's fault.

Consider two otherwise equivalent web server designs. They both use a helper
process owned by the user who owns the file the web server is sending. One
does a lot of work in the helper process, the other does very little. A
"fair by user" scheduler would give the approach that puts more work in the
helper process more CPU than the one that puts little work in the helper
process.

Indeed, it's a drawback. Though a configurable one.

Being fair by user builds lots of assumptions into the scheduler. When
they're not true, the scheduler becomes sub-optimal. For example, consider a
web server that runs two very important tools, 'foo' and 'bar'. Rather than
running them as root, they run as users 'foo' and 'bar' for security. "Fair
to user" would mean that just because most other people are using 'foo', I
get less CPU when I try to use 'foo', because the OS doesn't know the "real
user", just the fake user who owns the process -- a security decision that
has no relationship to fairness. This would be handled perfectly by a "fair
to process" approach.

Then, use a group quota. But checking that will be slower, and that
overhead might kill other gains.

As for favoring multi-threaded processes over single-threaded processes,
sometimes that's what you want.

Not on desktop.

Typical multi-threaded workloads:
- apache
- some P2P clients
- some audio servers/applications (small number of threads)

Single-threaded is much more popular.

Consider two servers,
^ ^ ^

Well, aren't we discussing desktops?
Server admins can fine-tune the rights and CPU quotas per group.

one using thread per
job the other using process per job. Does it make sense to give the "process
per job" server as much CPU to do a single task as the "thread per job"
server gets for all the clients it's dealing with?

Not necessarily. You see, the processes themselves are schedulable,
the threads aren't.


It's really more important that the scheduler be tunable and predictable.

This kind of scheduler, yes. Except it's much more tunable than a
simple fair or unfair scheduler, and much more suited to real-time
applications.

That way, we can tell it what we want and get it. But the scheduler cannot
read our minds.

That's why the per-user or per-group part would have to be optional.
It just doesn't make much sense on single-user desktops.
Then, RSDL design or even RSDL+bonus could be used.

The bonus part would have to be really simple, e.g. priority
inheritance for pipes, startup priority boost for nice 0 tasks.
(warning - fork bombs. :P )
No sleep estimator. Maybe these would suffice?

The interactive bonus would be disabled by default, same as
per-user/per-group scheduling.

Some syscalls would have to be added, maybe using LSM framework?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/