Date: Sun, 07 Nov 1999 20:54:25 -0700 From: "Russell L. Carter" <rcarter@chomsky.Pinyon.ORG> To: Julian Elischer <julian@whistle.com> Cc: freebsd-arch@freebsd.org, rcarter@pinyon.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <19991108035425.2161E80@chomsky.pinyon.org> In-Reply-To: Message from Julian Elischer <julian@whistle.com> of "Sun, 07 Nov 1999 02:45:04 PST." <Pine.BSF.4.10.9911070237440.10573-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
% %On Tue, 2 Nov 1999, Russell L. Carter wrote: % [...] %> %> Put another way, cramming a process's threads into a single %> scheduling quanta significantly diminishes the suitability of FreeBSD %> as a platform for building high performance and/or RT CORBA apps. % %Let's rephrase this.. ok, but first, apply: s/single scheduling quanta/single scheduling class/ to the above. Weak minded mistake, sorry. % %Firstly 'A single scheduling quanta' is probably a misleading statement. % %firstly it would be %'A group of quanta' as the process may be at a priority where it gets a %lot of time and there may be only one other process with only 1 quanta %allocated to it.. %99/100 is pretty close to all you can get.. Not hard realtime. This is the "best" that can be hoped for, and is certainly generous. But perhaps it could be tunable, down, what I'm concerned about is over allocation of resources required to meet weak QoS "guarantees" for things like streaming multimedia. And some other stuff. %secondly, I see a need to be able to effectively 'fork off a separate %family of threads' that are treated as a separate scheduling entity. %Thsi only makes sense at all if the threads in that group are explicitly %bound to that group, and other threads cannot arbitrarily wander in and %out of the group. Right. The spec explicitly supports this now. But as a specialization, I can think of no (money-making :-) application that requires a thread's scheduling class to be changed during the thread's lifetime (after initial thread initialization). So I think this restriction is useful. %The sum of the processing quanta for the original and the new class would %be the same as a user process forking to run 2 processes in parallel, and %would be limited by the same mechanisms. The second process could not %increaes its priority higher than the parent, just like nice(2) at the %moment. (You wuld need root priority to do that) Frankly, any unpriviledged user space process should abide by these rules, always. That's not the issue I thought; the issue is whether or not some processes (with root priviledges) in the system could take advantage of the soft realtime capabilities specified by the optional POSIX thread interfaces, and accessible via Peter D.'s modifications to the rtprio interface. Thread libraries such as LinuxThreads can do this, though flawed, today. And on top of those are built, well, look back at my other mails. Daniel alludes to priority inheritence for thread mutexes in his response. There's a lot underneath that issue! Schedulability is at the heart of the problem. It's not at all irrelevant to an OS with a reputation for high performance and reliable content delivery. Regards, Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991108035425.2161E80>