Date: Thu, 05 Oct 2000 22:30:53 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/alpha/include Message-ID: <XFMail.001005223053.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0010061529040.1822-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06-Oct-00 Bruce Evans wrote: >> - Change fast interrupts on x86 to push a full interrupt frame and to >> return through doreti to handle ast's. This is necessary for the >> clock interrupts to work properly. > > This interferes with my work (my version has fast interrupts restored to > almost their former state. They can't go anywhere near the scheduler and > remain fast (fast really means low latency)...). I almost didn't do this, but hardclock needs to post an ast(). >> - Change the clock interrupts on the x86 to be fast instead of threaded. >> This is needed because both hardclock() and statclock() need to run in >> the context of the current process, not in a separate thread context. > > This is not needed, and not possible if fast interrupts are actually fast > (clock interrupts touch too many objects which would need locking). Just > pass them the frame of process that was interrupted. Clock interrupts > only need a low priority since they are not used for timekeeping. Ahem. softclock is not run during the interrupt now, so hardclock isn't touching but so many things. Trying to pass around frames dosn't really work right, and still breaks scheduling. Without this change we don't really have timeslices, as hardclock() never pre-empts a process. Instead we relied on the need_resched() in the sched_ithd() function to trigger a reschedule. Since hardclock was run later on in a thread context, the need_resched() that it set was not processed until the next task entered the kernel either via an interrupt or a system call. Granted, since you will always have more clock interrupts coming in, the system still manages to function, but it was still bogus. >> - Remove CLKF_BASEPRI, which was #ifdef'd out on the x86 anyways. It was >> broken on the x86 if it was turned on since cpl is gone. It's only use >> was to bogusly run softclock() directly during hardclock() rather than >> scheduling an SWI. > > It was non-bogus on some arches (ones without SWI's...). Since it is a > macro, > it can be any machine-dependent condition that can be derived from the frame, > including "always false" if that is best for the arch. We don't have the same system of IPL's that it depends on present anymore, however. Also, since SWI's are now MI, they are on all arches. >> - Remove the COM_LOCK simplelock and replace it with a clock_lock spin >> mutex. Since the spin mutex already handles disabling/restoring >> interrupts appropriately, this also lets us axe all the *_intr() fu. > > This is a regression. There should be a separate lock for each fast > interrupt > handler (COM_LOCK should be per driver). Arg, this was a typo. I replaced CLOCK_LOCK with a clock_lock mutex. I do have some changes in my tree to use per-softc mutexes in sio to replace COM_LOCK, but that is a separate change I have not committed at the time being (and won't w/o your review). >> Submitted by: jakeb (making statclock safe in a fast interrupt) > > I don't think it is safe. E.g., rtcin() (called by rtcintr()) depended on > splhigh() for locking. Since splhigh() is null, rtcin() now depends on > the giant lock. I wouldn't want all accesses to the rtc to be protected > by clock_lock. Actually, the code uses the sched_lock to protect the things it accesses, which blocks interrupts and effectively runs at splhigh(). > Bruce -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001005223053.jhb>