Date: Fri, 6 Oct 2000 16:17:37 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha trap.c src/sys/alpha/include cpu.h globals.h src/sys/i386/i386 genassym.c globals.s machdep.c mp_machdep.c swtch.s trap.c src/sys/i386/include asnames.h cpu.h globaldata.h globals.h lock.h mutex.h smptests.h src/sys/i386/isa ... Message-ID: <Pine.BSF.4.21.0010061529040.1822-100000@besplex.bde.org> In-Reply-To: <200010060220.TAA72199@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> - 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)...). > - 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. > - 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. > - 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). > 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. Bruce 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?Pine.BSF.4.21.0010061529040.1822-100000>