From owner-freebsd-bugs  Thu Sep 19 19:20:06 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA04591
          for bugs-outgoing; Thu, 19 Sep 1996 19:20:06 -0700 (PDT)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA04571;
          Thu, 19 Sep 1996 19:20:02 -0700 (PDT)
Date: Thu, 19 Sep 1996 19:20:02 -0700 (PDT)
Message-Id: <199609200220.TAA04571@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bruce Evans <bde@zeta.org.au>
Subject: Re: kern/1652: Version roif itimer patch for -current
Reply-To: Bruce Evans <bde@zeta.org.au>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/1652; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@freebsd.org, julian@current1.whistle.com
Cc:  Subject: Re: kern/1652: Version roif itimer patch for -current
Date: Fri, 20 Sep 1996 12:09:18 +1000

 >It is possible that this should only be called if delta is greater than a particular
 >size.
 
 No, delta is very unlikely to be small (else adjtime() should have been
 used instead of settimeofday()), and whatever you do to handle large
 adjustments should also work for small adjustements.
 
 >Also SPL must be considered if the number of processes is large..
 
 Yes, walking the queue at splclock() defeats the micro-optimized spl
 placement in settimeofday().  It think atomic update is only necessary
 for each itimer, not for all of them together.
 
 >I could check this in myself, but I want comments first..
 
 Mihoko Tanaka <mihoko@pa.yokogawa.co.jp> posted a similar fix the other
 day.
 
 All versions forgot to remove or update the load comment about this problem.
 
 I wonder why this problem has been around for so long, and why adjkerntz
 doesn't seem to cause it.
 
 Bruce