From owner-freebsd-current@FreeBSD.ORG Fri May 7 00:46:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BCF816A4CE; Fri, 7 May 2004 00:46:26 -0700 (PDT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3449A43D49; Fri, 7 May 2004 00:46:25 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i477kN4u000550; Fri, 7 May 2004 17:46:23 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i477kKHW006234; Fri, 7 May 2004 17:46:21 +1000 Date: Fri, 7 May 2004 17:46:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: David Schultz In-Reply-To: <20040507040852.GA78023@VARK.homeunix.com> Message-ID: <20040507165839.Q24428@gamplex.bde.org> References: <20040507005518.75B6A79004C@ws1-14.us4.outblaze.com> <20040507040852.GA78023@VARK.homeunix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: "P.D. Seniura" Subject: Re: low HZ value causes "Time Warp Bug" (re: this Puny Pentium2 suddenly became 45% slower!) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 07:46:26 -0000 On Thu, 6 May 2004, David Schultz wrote: > On Thu, May 06, 2004, P.D. Seniura wrote: > > > > > > It seems this bug happens when the HZ value goes below 16 > > > > (either by compiling 'options HZ=' in kernel or setting > > > > sysctl 'kern.hz=' in /boot/loader.conf). The computed > > > > 'ticks' value becomes too large for 2-byte int producing > > > > crazy overflowed numbers elsewhere. > > > > > > 16 is pretty low.. > > > Then again it would be nice if it warned you or something similar when you > > > tried it :) Nah, INT_MIN would be low. Values between INT_MIN and -1 might cause even more interesting behaviour. The value of 0 would cause the not so interesting behaviour of a panic for division by 0 in init_param1() if not earlier. Nonexistent bounds checking for hz is just one of thousands of cases of nonexistent bounds checking for tunables and sysctls. The kernel trusts the (privileged) user not to set values that don't work. WHere is the 2-byte int that overflows? The kernel mostly uses "int ticks = 1000000 / hz". It assumes at least 32-bit ints or that hz > 2. This will work until hz becomes larger tha 1000000 or not nearly a divisor of 1000000. > > > > Heh, I got HZ set to 20 while it does > > buildworld (~9 hours) and portupgrade overnight. > > The idea is "less slicing and more doing". ;) > > Umm...yeah, don't do that. For one, 1/(100 Hz) = 10000 us = 4.5 > million cycles on your processor, which is an eternity in computer > time. For two, HZ doesn't affect the maximum timeslice processes > get. The scheduling quantum is fixed at 100 ms in the 4BSD > scheduler, and it varies between 10 ms and 143 ms in ULE. Actually, it is supposed to be non-fixed at the value set by the kern.quantum sysctl in the 4BSD scheduler, but this was broken a few years ago: %%% ---------------------------- revision 1.156 date: 2001/02/12 00:20:05; author: jake; state: Exp; lines: +4 -3 ... - Remove the curpriority global variable and use that of curproc. This was used to detect when a process' priority had lowered and it should yield. We now effectively yield on every interrupt. ... %%% This commit didn't break the quantum; that was done a year or so earlier by yielding on every interrupt (actually only on non-fast interrupts, so the quantum might still work if there were only clock interrupts and curpriority and related things had not rotted). The yielding is just be switching to interrupt threads. On switching back, at least the 4BSD scheduler doesn't really know what the interrupted thread or its quantum was. It just picks the highest priority runnable thread, and that is never the interrupted thread if there are multiple threads with the same priority, since yielding puts the interrupted thead on the tail of the queue. Scheduling is thus reduced to essentially round-robin among threads with the same priority, with a variable quantum of