Re: Comments on the KSE option

>From Julian Elischer <julian_at_elischer.org>, Fri, Oct 27, 2006 at 12:27:14PM -0700:
> The aim of the fair scheduling code is to ensure that if you, as a user, 
> make a process that starts 1000 threads, and I as a user, make an 
> unthreaded process, then I can still get to the CPU at somewhat similar
> rates to you.  A naive scheduler would give you 1000 cpu slots and me 1.
Ah.  Let me be one of the first to take a crack at attacking this idea as
a mistake.

First the name-calling: What you're talking about is communist scheduling.
It insists that I the user should conform to the scheduler's notion of the
right ratio of processses to threads.

Now the serious response:
By fair-scheduling what you mean is recreating through quite a bit of
computation some of the scheduling defects of libc_r: namely that threading
is denied the same concurrency granted to multi-process based architectures.
I now rather instantly apprehend why multi-threading has lagged behind so
much on FreeBSD.

Let me tell you right now, this is not an assumption people consider when
multithreading their applications.

Can you offer an explanation as to why the scheduler should care about the
balance of active users/active threads/active processes?

If you desire partitioning there is a simple answer: rlimits covering the
number of threads, processes, threads per process, etc.

And hint: almost everyone will turn these limits off.

The only necessary fairness property is between threads.

The scheduler cannot ascertain among several threads which are doing
important work merely by virtue of how they are distributed among the
vmspaces (processes).  This sort of distinction should be left under
the control of process priority, thread priority, and rlimits.

                                      Paul