Re: Comments on the KSE option

Paul Allen wrote:
From Daniel Eischen <deischen@xxxxxxxxxxx>, Fri, Oct 27, 2006 at 04:41:16PM -0400:
On Fri, 27 Oct 2006, Paul Allen wrote:

>From Julian Elischer <julian@xxxxxxxxxxxx>, 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
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Win32 Event vs Conditional variable
    ... oriented for preemptive scheduling ... POSIX condition variables have exactly one use: ... there is a fairness requirement for broadcast and therefore user- ... producer in cases that there are enough consumers that are not going ...
    (comp.programming.threads)
  • Re: Comments on the KSE option
    ... The aim of the fair scheduling code is to ensure that if you, as a user, ... you want, within rlimits of course. ... an rlimits mechanism that will allow the machine to be saved before it ... is priorities not thread grouping per process. ...
    (freebsd-current)
  • Re: question on enforcing fairness between threads
    ... it's not fair to impose the COST of fairness on those who don't want fairness. ... Even a "fair scheduling" option would add overhead to the scheduling paths everyone uses. ... There are plenty of ways to build whatever sort of fair behavior you want on top of EFFICIENT primitives, but no way to build EFFICIENT behavior on top of FAIR primitives. ... Instead of using the default queuing order for mutexes you can block and unblock your threads in any order you want. ...
    (comp.programming.threads)
  • Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
    ... same amount of CPU". ... That's a totally illogical measure of fairness. ... So I'm not excluding extra scheduling classes like per-process, per-user, ... trying to figure out the wakeup matrix. ...
    (Linux-Kernel)
  • Re: Win32 Event vs Conditional variable
    ... oriented for preemptive scheduling (i.e. due to fairness constrains) ... POSIX condition variables have exactly one use: ... scheduling contention for some amount of time, ...
    (comp.programming.threads)