Re: Comments on the KSE option

>From Daniel Eischen <deischen_at_freebsd.org>, Fri, Oct 27, 2006 at 04:41:16PM -0400:
> On Fri, 27 Oct 2006, Paul Allen wrote:
> 
> >>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.
> 
> No, it is POSIX.  You, the application, can write a program with
> system scope or process scope threads and get whatever you behavior
> you want, within rlimits of course.
So your argument is: "if I can find a spec that does it, its right"
Sorry but if you participated in more spec writing--I do, in the IEEE--
you'd realize that was not a good position from which to argue.  Plenty
of mistakes are made in specs.

Let me reiterate, that either because of poor education or choice,
multithreading is not usually implemented in a manner consistent 
with your scheme.

Threads are either busy (have work to do, in which case the kernel
shouldn't be making value judgements except by way of priority) or
they are sleeping in which case the point is moot.

Preventing users from interfering with each other on a multiuser system
is a problem for rlimits to solve.

On a single user-system, having an imbalance of consumer/producer threads
is a configuration problem which again the safety net necessary is
an rlimits mechanism that will allow the machine to be saved before it
falls over.

The 1000 versus 1 is still some sort of strange academic fairness fetish.
If the process with one thread is relatively (per thread) more valuable 
that should be reflected in the scheduling priorities and implemented
in the scheduler using a mechanism similar to WFQ.  Again though: this
is priorities not thread grouping per process.

Irrespective of that, the number of threads is usually set to match
the workload and its importance.

Don't you think its better for code-paths to optimized for the common case?

                                       Paul