Message-ID: <f44c5fdf0703190627x43427f26qaed948aed71847ad@mail.gmail.com>
Date:	Mon, 19 Mar 2007 14:27:21 +0100
From:	"Radoslaw Szkodzinski" <astralstorm@...il.com>
To:	davids@...master.com
Cc:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: is RSDL an "unfair" scheduler too?

On 3/19/07, David Schwartz <davids@...master.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists