Date: Sun, 2 Aug 1998 06:18:10 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: tlambert@primenet.com (Terry Lambert) Cc: dufault@hda.com, mike@smith.net.au, chanders@timing.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Using FreeBSD for data acquisition? (long) Message-ID: <199808021018.GAA15812@hda.hda.com> In-Reply-To: <199808012202.PAA26932@usr07.primenet.com> from Terry Lambert at "Aug 1, 98 10:02:49 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > 1 seconds is the round robin scheduling interval. It appears (.1 seconds obviously) > > 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. You're right - you may be in the kernel and obviously can't always preempt the process. But look at wakeup() in kern_synch: it does a need_resched, which is an AST to the context switching code in swtch.s. I thought this would happen as soon as the CPU is executing in user context, preempting the current process before the scheduling quantum expires. I'll read your missive later. However, from past experience, I know that you and I have fundamentally different opinions about the benefits of preallocation of resources (including CPU time) in tightly controlled and limited environments. 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?199808021018.GAA15812>