Date: Fri, 22 Jan 1999 22:59:27 -0600 (CST) From: Kevin Day <toasty@home.dragondata.com> To: dyson@iquest.net Cc: rcarter@pinyon.org, dyson@iquest.net, dufault@hda.com, dillon@apollo.backplane.com, hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change Message-ID: <199901230459.WAA06844@home.dragondata.com> In-Reply-To: <199901230415.XAA62055@y.dyson.net> from "John S. Dyson" at "Jan 22, 1999 11:15:10 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Russell L. Carter said: > > %> > > %Your comments about "goals" are correct. The obsolete notion of priority > > %is specious. > > > > No, it isn't. > > > > People (or rather organizations) are now using "OSS unix" stuff to > > do things like control flight and targeting and other interesting > > stuff. The lingo is based on "priority". Who gives a shit > > about interactive users ;-). Meeting deadlines is probably > > orthogonal to system throughput. > > > Deadlines are a major parameter. Even responsiveness to users > is a form of deadline. Priority is only a short term scheduling > hint, and doesn't really describe the resource requirements. Priority > is a snapshot of what needs to run at an instant in time. Priority > as a time invariant scalar (or even as the unix style slowly changing > priority) isn't flexible enough anymore. Since we are talking here > about resource mgmt, constraining ourselves to thinking about "priority" > is just too inflexible. > > When looking into alternative scheduling mechanisms, priority > just doesn't describe an adequate solution to the new range > of problems (multimedia scheduling, realtime data, timesharing), > that need to be solved concurrently (perhaps with the same > resources.) > I can agree here.... I've got a somewhat unique embedded system I'm working on, that it's goals aren't too different from a desktop PC, but very 'deadline' oriented. Just boosting artificial priorities up and down doesn't really help. I end up cutting off processes needlessly, or missing events that I can't afford to miss. I've modified FreeBSD's scheduler a bit to work for my case, but what I'd really love to see is something that I can tell the scheduler that "I need to execute again in x ms (or even ns)". Possibly setting a range of acceptible sleeping. I also want to be able to say that a process, while not going to sleep, if it's going to get execution taken away, it needs to be brought back, and finish something before x amount of time. Simply dinking with rtprio is really inadequate for a true realtime system. (It does help having it there, though) Also being able to temporarily change things on the fly in reaction to some kind of input would be ideal, then transparently resume it's previous settings. My system has one process that blocks on a read() on an input device, who then places the data it just read into a shared memory queue, then signals processes who are consumers of this data that there's new data there, then, if any of those need to react to what they just learned, they wake up the another process to give it their output. All three processes need to execute in as close as possible order, within a short amount of time, to ensure the input/output delay doesn't seem sluggish. Some way to schedule this would be nice, so I don't have to roll completely seperate things into one big process, or somehow make one process be able to set a 'run next' flag on another process in the scheduler. Another feature that would be nice would be highly accurate timers or alarms. Trying to sync a movie playback to vsync on a display is very difficult if you don't have access to a vblank interrupt. This also could be used for waiting for somewhat slow devices, that nanosleep(1)'s resolution is still too large for. (nanosleep(1) seems to sleep about 2-10ms on an idle system) But... This is deviating quite a bit from what you guys are talking about, and I'm probably quite an exception to what is normally done with fbsd, than the majority. Kevin 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?199901230459.WAA06844>