Date: Wed, 3 Apr 1996 01:27:15 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, toor@dyson.iquest.net Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de, phk@critter.tfs.com Subject: Re: calcru: negative time: Message-ID: <199604021527.BAA29463@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604021527.BAA29463>