Re: Comments on the KSE option

Paul Allen wrote:
>>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.

That scheme is optional... if you want it you can use it, and if
not you can turn it off.. At least, it was designed to be that
way though some of it may have been obscured during the evolution
of the code. What you are saying is that users on a multiuser system 
expect that if they make more threads they can monopolise the system?

In machines that are dedicated to a single task the admin is welcome
to let that task hog as much as possible. When it is supposed to
be shared, that is probably NOT the expected behaviour.

> 
> 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.

exactly, but often you get bursts of work where may many threads come to 
life. Does that mean everything else should stop?

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

What would you put in rlimit to solve this problem? Be specific!
Please send diffs and code outlines.


> 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.

On a single user system this can all be disabled anyhow..
which is why I suggest that the KSE option recently added be broken
into a M:N option and a FAIRNESS option.

> 
> 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.

This is a question for the project as a whole to decide.
As I said.. "do we want 'fareness' or not?"
If not then a lot of simplification can occur. But we need to be clear
on the fact that when this is ripped out it will be a one way street.
It will be hard to put back once evolution has moved the code a bit.

If we DO want some fairness, then how much, and what sort?
We probably need to implement a better version of it
than the current version.. It's just that when we decided to go
ahead with threading in 1998, we decided that we need some
form of fairness, and I put in the simplest possible example of
strict fairness that I could think of. It's not elegant and it
is definitely expensive.
I had expected that some PhD would have replaced it by now.

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

But that depends if you are the only user, or a student doing a project 
on a shared machine.

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

the code paths can actually be optimised.. they just haven't been yet.

> 
>                                        Paul
>