From owner-freebsd-bugs Sun Sep 22 17:09:59 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA13788 for bugs-outgoing; Sun, 22 Sep 1996 17:09:59 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA13745 for ; Sun, 22 Sep 1996 17:09:54 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id RAA18290; Sun, 22 Sep 1996 17:08:06 -0700 (PDT) Message-ID: <3245D481.7566F4CF@whistle.com> Date: Sun, 22 Sep 1996 17:06:25 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Bruce Evans CC: freebsd-bugs@freefall.freebsd.org Subject: Re: kern/1652: Version of itimer patch for -current References: <199609200220.TAA04571@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > From: Bruce Evans [...] > >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 [...] Ok so that part stays the same.. no such optimisation.. > > >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. hmm do you think we need any particular locking then? will we break SMP stuff? etc. etc. would doing it a splsoftclock be sufficient? if so, how about the fix below? do we need to lock the process list for SMP ops? > > >I could check this in myself, but I want comments first.. > > Mihoko Tanaka posted a similar fix > the other day. yes and I think we need to do this.. > > All versions forgot to remove or update the load comment about > this problem. eh? Oh you mean the comment in the code? yeah ok, if I did this I'd change the comment.. :-) > > I wonder why this problem has been around for so long, and why > adjkerntz doesn't seem to cause it. sorry I don't follow.. adjkerntz? that doesn't change the internal time does it? just how we express it? Oh I see, because we interpret the cmos clock differntly..? well that will only be at most 24 hours, or 3600x24 loops. Where we are talking about year sized changes.. > > Bruce o how about the following variation? (using splsoftclock) (warning.. cut+paste used) *** 1.17 1996/07/12 07:55:35 --- kern_time.c 1996/09/23 00:04:46 *************** *** 56,61 **** --- 56,62 ---- */ static void timevalfix __P((struct timeval *)); + static void recalc_realtimer(struct timeval); #ifndef _SYS_SYSPROTO_H_ struct gettimeofday_args { *************** *** 114,120 **** (error = copyin((caddr_t)uap->tzp, (caddr_t)&atz, sizeof(atz)))) return (error); if (uap->tv) { - /* WHAT DO WE DO ABOUT PENDING REAL-TIME TIMEOUTS??? */ s = splclock(); /* * Calculate delta directly to minimize clock interrupt --- 115,120 ---- *************** *** 136,141 **** --- 136,142 ---- timevalfix(&delta); timevaladd(&boottime, &delta); timevaladd(&runtime, &delta); + recalc_realtimer(delta); LEASE_UPDATETIME(delta.tv_sec); splx(s); resettodr(); *************** *** 144,149 **** --- 145,164 ---- tz = atz; return (0); } + + + static void + recalc_realtimer(struct timeval delta) + { + struct proc *p; + + for (p = allproc.lh_first; p != 0; p = p->p_list.le_next) { + if (timerisset(&p->p_realtimer.it_value)) { + timevaladd(&p->p_realtimer.it_value, &delta); + timevalfix(&p->p_realtimer.it_value); + } + } + } extern int tickadj; /* "standard" clock skew, us./tick */ int tickdelta; /* current clock skew, us. per tick */