Date: Fri, 9 Apr 1999 05:21:14 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: julian@whistle.com (Julian Elischer) Cc: dillon@apollo.backplane.com, dg@root.com, dyson@iquest.net, aron@cs.rice.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: scheduling queues in FreeBSD Message-ID: <199904090921.FAA23160@hda.hda.com> In-Reply-To: <Pine.BSF.3.95.990408184048.4355D-100000@current1.whistle.com> from Julian Elischer at "Apr 8, 99 06:43:32 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, 8 Apr 1999, Matthew Dillon wrote: > > > > I think it would be useful for 'idle' priority processes, but I agree > > that it would not be useful for any sort of true 'realtime' ( i.e. > > when there is more then one realtime process ). But the existing > > realtime scheduler isn't useful for true realtime either since there > > are no scheduling primitives. > > Before getting too excited by the possibility of a code massacre.. > you should check with Peter Dufault. > I believe some people are using this in production and I have even done so > myself at times. > > One tends to hardly ever need 32 queues in all three categories > (well I haven't) but it's be a bummer to lose the functionality > entirely. > > As I said.. Please make sure you here from Peter D before you act as he's > involved in this sort of thing.. I'm involved with a small medical device company at a critical stage in their business, and I'm the only one there who understands software or digital hardware and that will change only when the "something big" that is happening now finishes happening. I'm pointing this out to explain why I never committed those patches, which I thought were OK, as I know some folks want them badly: 1. I wouldn't have the time to support them properly if there were problems; 2. Bruce didn't like them because they were too invasive, moving things around in the kernel source (and they probably had lots of style bugs). If someone with some spare cycles would like to adopt them then on Sunday I'll get them to patch against -current again, they can then pick them up and run with them. As for scheduling, here is the way I will go when and if I get the time and especially if I get the grant I'm applying for: I'd like to see all scheduling related stuff in one module that can be replaced; To get toward real time I'd extend the concept of scheduling classes and add CPU resources. CPU resources are either multiple CPUS or a time multiplexed CPU with time reserved for real time processes. In this second case you'd essentially have something similar to an SMP kernel running on a single CPU. CPU resources would have a bitmap of permitted scheduling classes that were allowed to be scheduled on them. Multiple scheduling classes eligible to run on a single CPU resource would be ordered by priority, treating them as if they were a single priority queue. A CPU resource running a process marked as "real real time" would signal the process if something happened that wasn't determined to be real time safe. This would include many system calls and handling an interrupt other than a fast interrupt. Fast interrupt related code would be verified to be reentrant. Then in an MP realtime system a process would set everything up, become the scheduling class that had a second CPU dedicated to it and thus become realtime. If your analysis was screwed up or during debugging it would catch the you-screwed-up signal. Anyway, that is what I'll do if I have time. Oh, and transitive closure. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904090921.FAA23160>