Date: Fri, 12 Sep 1997 04:02:56 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dgy@rtd.com (Don Yuniskis) Cc: freebsd-hackers@freebsd.org Subject: Re: Realtime Programming Under FreeBSD? Message-ID: <199709120402.VAA13813@usr03.primenet.com> In-Reply-To: <199709120100.SAA16409@seagull.rtd.com> from "Don Yuniskis" at Sep 11, 97 06:00:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Perhaps I read more into Peter's comments than he intended *but* I
> was under the assumption that his (perhaps too subtle?) statement
> that "running something completely orthogonal to the kernel" was
> intended to imply that there was *no* resource sharing (hence
> magically waving aside the priority inversion issues :>)? If
> *not*, then I believe the "processor reserves" approach would need
> to be more integrated into the kernel to make those claims...
Yes. This was clarified after the posting to which you are responding;
you are correct that he meant completely orthoganal scheduling.
This will never fly, of course, since it means that the overall
system performance will be degraded in the general case.
There is also the issue of whether or not "1 quantum every n quanta"
is sufficient for most RT tasks. For the original poster's 1000Hz
requirement, it's not. I realize that it *is* generally useful in
terms of actually being an HRT soloution, but without an application,
the degradation of the general system is too high a penalty to pay
for something which might never see use because of the clock resoloution.
Cranking up the Hz will solve that problem, but add to the issue
of overhead by increasing by a factor of 10 the context switch
overhead. Not good. 8-(.
> > If you had (1) kernel preemption, and (2) a reschedulable interval
> > based one-shot timer, you would have the basis of a hard timing
> > constraint for when you could begin some act. That leaves issues
>
> I think the one-shot can be worked around (assuming the system tick
> is at a frequency "high enough for the timeliness constraints of the
> application") since you could just ensure the events are scheduled
> prior to the tick *before* the deadline, etc. (i.e. err on the
> earlier side)
Maybe if it buzzed to the the actual start time. It is just as bad
to grab before the bottle as after, in the bottling plant example.
The real bitch with deadlining is that you have to know how long
the operation will take to complete, within the hard resoloution,
before you start the operation to complete *at* the deadline. It's
not just >= for the bounds function, it's a hyperbolic tangent.
The max time required to preempt a resource (which resolves the
inversion problem -- lending is an SRT soloution, unless you
account for the time it takes an inverted request to completion
at the lent priority) defines your "hardness" function.
> > of priority inversion of shared resources, but that handleable
> > through (a) lending, and (b) resource preeemption. The other
>
> Yikes, Terry... you make it sound like it's *trivial*!! :>
> ("I'll expect those changes on my desk before 5PM...")
It's not trivial, but it *is* a systems engineering problem that is
amenable to a systems engineering soloution. And a large part of
the work is going to be "free" in any case, with other necessary
work. Maybe it's my view of the other necessary work that's different?
Topologically, the issue of SMP kernel reentrancy on an interrupt
or a fault (ie: event based entry rather than user requested entry)
is identical to the soloution required for the general case of
kernel preemption.
Topologically, the issues of kernel threading are identical to the
issues of kernel reentrancy via user request. The only real
difference is whether or not the synchronization primitive needs
to operate across multiple CPU's (mutex) or not (semaphore).
It remains to be able to tie a kernel thread RT based preferential
wakeup to a timer event of subquanta resoloution. The system quantum
clock need not change, and in fact the audio and profiling stuff that
need the fast clock code could be relaces with the same reschedulable
one-shot you would use to do this. In the grand scheme of things, this
type of thing is required to be able to permit concurrent device
initialization, and to get rid of the buzz loops used to satisfy timing
constraints for unfifo'ed devices. Like a floppy tape driver that
doesn't need a user space program at a pseudo RT priority in order to
not desynchronize the requests, or an LED toggle on the keyboard
requiring a delay in keyboard processing to safely turn the channel
around without locking the keyboard controller up. Etc.. Ideally,
all buzz loops of greater than some tiny value would become one-shots.
The trick here is that the one-shot code must have a deterministic
cycle count so it can remove its own time from the requested intervals
between events. A repeating time of any desired frequency can be had
by rescheduling the one-shot in the call-out.
For 486's the cycle count is harder. For 586's and above, you can
read the cycle counter on the CPU. That's what it's there for: RTOS's.
It's all related. It's a systems engineering problem.
A good RT implementation falls out of the combination of a good kernel
threading implementation and an SMP implementation, and a seperation
into preferential scheduling queues (which truly *is* trivial, and
itself will fall out of a good CPU affinity mechanism for SMP). The
only new thing you do to the kernel is subsystem latency tweaks to
decrease the time threshold over which the RT implementation is HRT.
After all is said and done, the only really complicated work is figuring
back from the deadline for the process itself -- and for RT processes,
these are things that have to be done by RT programmers anyway, no matter
what the underlying system implementation.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709120402.VAA13813>