Re: Comments on the KSE option

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.

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

_______________________________________________
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: [PATCH] 2.6.0 batch scheduling, HT aware
    ... |>>>crossover of 5 static priorities before things got queued together. ... But WRT the whole HT scheduling, it would seem that ideally you want to ... All of the recent scheduler work from Nick, Con and Ingo has ...
    (Linux-Kernel)
  • Re: VMS process priorities and system processes
    ... could otherwise block critical server processes. ... > priorities on specific priorities. ... > "The class scheduler provides the ability to limit the amount of CPU ... > enabled for their scheduling class. ...
    (comp.os.vms)
  • Re: [PATCH] [request for inclusion] Realtime LSM
    ... separate scheduling class at all. ... SCHED_RR, possibly with all their priorities intact, but for there to be ... other soft real time tasks go to SCHED_NORMAL, ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Comments on the KSE option
    ... priorities, that I'd rather they not actually use. ... them on a single operating system and in a single operating ... All a program can ever really do when requesting POSIX scheduling ... system scope threads in the system (from all applications, ...
    (freebsd-current)
  • Re: Comments on the KSE option
    ... you want, within rlimits of course. ... If the process with one thread is relatively more valuable that should be reflected in the scheduling priorities and implemented ... If we DO want some fairness, then how much, and what sort? ...
    (freebsd-current)