Re: Comments on the KSE option

Daniel Eischen wrote:
On Sat, 28 Oct 2006, Matthew Dillon wrote:


(2) Just because the POSIX scheduler implements all sorts of different
scopes and priority schemes says NOTHING AT ALL about how programs
operating under such a scheduler should be apportioned cpu relative
to OTHER PROGRAMS WHICH ARE INDEPENDANTLY RUNNING ON THE SYSTEM. POSIX
is an abstraction (or virtualization out of available resources),
just like everything else. If you try to treat it as a hard requirement
the only result will be a broken system that might happily run everything
else into the ground and stop allowing root ssh logins in order to
accomodate a badly written POSIX program. There are many third party
applications that set POSIX priorities, in particular realtime
priorities, that I'd rather they not actually use. Most of these
programs set these priorities based on the author's attempt to tune
them on a single operating system (e.g. linux) and in a single operating
environment.

All a program can ever really do when requesting POSIX scheduling
resources is compete against itself. It is the system operator, at a
higher level, that must control how those resources compete with
other programs. That should be clear to everyone it is so obvious.

Actually, that's not quite true. I assume you know the thing you
left out: system scope threads compete against all the other
system scope threads in the system (from all applications, not
just within one application).


All this debate about the merits of process scope threads and fair
scheduling is great. But tell me, who was working on making this stuff
work well quickly and reliably (i.e. work well)? No one! I don't care
what AIX or Solaris or what else may or may not have done, who was making this work well for FreeBSD? Having a slow a thread subsystem is
a serious detriment, no matter how nice and flexible it looks on paper.

Scott

_______________________________________________
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: Comments on the KSE option
    ... accomodate a badly written POSIX program. ... priorities, that I'd rather they not actually use. ... them on a single operating system and in a single operating ... system scope threads in the system (from all applications, ...
    (freebsd-current)
  • Re: Hyper-Threading Vulnerability
    ... > This is not a kernel problem, but a user space problem. ... we recommend that existing operating systems provide the ... necessary avoidance of inappropriate co-scheduling by never scheduling ... the first thread associated with each processor core. ...
    (Linux-Kernel)
  • 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)