From owner-freebsd-current Tue Apr 2 07:31:35 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02409 for current-outgoing; Tue, 2 Apr 1996 07:31:35 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02401 for ; Tue, 2 Apr 1996 07:31:30 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id BAA29463; Wed, 3 Apr 1996 01:27:15 +1000 Date: Wed, 3 Apr 1996 01:27:15 +1000 From: Bruce Evans Message-Id: <199604021527.BAA29463@godzilla.zeta.org.au> To: bde@zeta.org.au, toor@dyson.iquest.net Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de, phk@critter.tfs.com Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >If there are some times where splhigh() is on for too long, that needs >to be changed (we aren't using another interlock mechanism when we >should be.) Splhigh is correct for it's intended purpose -- lock out >ANY other access to the VM data structures. Splimp is just a hack in splvm() would be correct. splhigh() locks out access to _all_ data structures. AFAIK, hardclock() doesn't touch any vm data. statclock() touches some vm statistics. This could probably be handled without locking so much. statclock() is careful not to touch user pages for profiling ticks. This may depend on our fuswintr() and suswintr() always failing so that profiling ticks aren't added immediately. slimp() doesn't contain splbio(), so it must have once been safe to handle disk interrupts in the middle of vm operations. Has this changed? splhigh() is more or less the union of splimp() (which is usually >= spltty() due to other bogins), splbio() and the clock part of splclock(), so the switching from splimp() to splhigh() was essentially adding the masking of bio interrupts together with (unnessarily I hope) adding the masking of clock interrupts. Bruce