Date: Sat, 1 Aug 1998 22:02:49 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dufault@hda.com (Peter Dufault) Cc: mike@smith.net.au, chanders@timing.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Using FreeBSD for data acquisition? (long) Message-ID: <199808012202.PAA26932@usr07.primenet.com> In-Reply-To: <199808011010.GAA13588@hda.hda.com> from "Peter Dufault" at Aug 1, 98 06:10:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > This would tend to indicate a possible problem with the interaction > > between your interrupt handler and the read handler, but it's > > impossible to tell without seeing the code. > > 1 seconds is the round robin scheduling interval. It appears > the wakeup from the driver isn't preempting the current process, > but waiting until the next roundrobin call. As far as I can tell, > wakeup should preempt it. Kernel preemption is topologically equivalent to any other reason for kernel reentrancy, from kernel threading to allowing all the processors in an SMP system simultaneous entry. When you wakeup a process, you put it on the read-to-run queue, you *don't* context switch it to be active. This is because a wakeup can occur at interrupt level. In the case of a process on the RTPRIO queue, it gets to run first after the quantum is ceded by the process that did the waking; or rather it gets in line to run first, if you are running many things at RTPRIO. One thing you could do would be an explicit yield after the wakeup, to put the waking process to sleep immediately. If you have stuff that need to get done before the next cycle, however, this would be a mistake, since that would mean your processes were in fact coprocesses. This will also not help you in the case of a wakeup not under your control; such processes will not relinquish quantum voluntarily (you don't want voluntary cooperation in RT in any case; it requires too much trust). For interrupt level wakeups, this is more complicated; if you have extra work to do, it should be done before the yield, or it should be queued for deliveray as a software interrupt once you exit interrupt context back to the scheduler. One could argue that there are such things as RT soft interrupts, which sould result in the preemption of the interrupted process by the soft handler. 8-(. What you really need are serious modifications to support RT via scheduler and wakeup changes for kernel preemption; even then, the best latency you can guarantee is the latency you get when you wait for everyone to either be in the kernel asleep, or out of the kernel. This avoids cases where you try to preempt, for example, an FS operation on the kernel stack, and end up with priority inversion over access to a directory vnode. That is, your maximum latency is the most expensive interrupt handler, or the longest possible non-blocking call path not protected by an explicit nod in a lock graph. I believe you did some of this code a long time ago on the unofficiall (not hosted centrally) FreeBSD RT list. 8-). > 1. Having a way to know you missed your deadline, either in hardware > or using the CPU time stamps, for debugging your system and > testing new releases; Deadlining has different requirements. It implies full kernel reentrancy. If deadlining is to start, rather than to completion, it's much easier; otherwise you must also know the maximum amount of time the code that is going to be run will take to run, so you can reverse-bias the deadline to an earlier point. The difference between the minimum and maximum time *must* be such that, if you start at the earliest required time, you don't finish before you are permitted to finish -- in other words, "get done after X, but beofre X + N" is a bitch of a constraint. 8-(. You end up with contstraint-based data structures instead of just deadline-based structures. Do not expect completion deadlining in FreeBSD in excess of latency, if all you do is the necessary wakeup/scheduler hacks. > 2. Doing your latency critical work in the kernel. > > You still have to keep an eye out for misbehaving device drivers > turning off interrupts, etc. Right. This implies a hardware event, rather than a software event is the trigger that sets the deadline. If it's software, then you have to use a virtual event, probably shoddily derived from a timer interrupt at some point. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199808012202.PAA26932>