From owner-svn-src-head@FreeBSD.ORG Wed Oct 29 11:34:42 2008 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85B411065674; Wed, 29 Oct 2008 11:34:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1E3788FC25; Wed, 29 Oct 2008 11:34:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-151-199.carlnfd1.nsw.optusnet.com.au [122.106.151.199]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m9TBYcd4007961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2008 22:34:40 +1100 Date: Wed, 29 Oct 2008 22:34:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Maxim Sobolev In-Reply-To: <4906ECC1.4080907@FreeBSD.org> Message-ID: <20081029220255.B4187@besplex.bde.org> References: <200810261858.m9QIw4YV091893@svn.freebsd.org> <200810271411.11813.jhb@freebsd.org> <20081028202701.E85964@delplex.bde.org> <4906ECC1.4080907@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, John Baldwin , Bruce Evans Subject: Re: svn commit: r184293 - in head/sys: amd64/amd64 i386/i386 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2008 11:34:42 -0000 On Tue, 28 Oct 2008, Maxim Sobolev wrote: > Bruce Evans wrote: >> On Mon, 27 Oct 2008, John Baldwin wrote: >> >>> On Sunday 26 October 2008 02:58:04 pm Maxim Sobolev wrote: >>>> Author: sobomax >>>> Date: Sun Oct 26 18:58:04 2008 >>>> New Revision: 184293 >>>> URL: http://svn.freebsd.org/changeset/base/184293 >>>> >>>> Log: >>>> Fix division by zero panic if kern.hz less than 32. >>>> >>>> MFC after: 1 day >>> >>> This is wrong. In the case you are worried about here, lapic_timer_hz is >>> less >>> than 128. There is no way you are going to fire stathz 128 times per >>> second >>> from a timer running at < 128 hz. You are effectively running stathz at >>> lapic_timer_hz, so I would just set stathz = lapic_timer_hz in this case. >> >> stathz needs to be about 128 to work as intended, at least for SCHED_4BSD. >>> ... >> Also, hz = 10 cannot work on i386 without lapic_timer, since the i8254 >> timer >> has a maximum interrupt period of 55 ms and thus a minimum frequency of >> 18.2 Hz. Attempts to set it to 10 Hz cause similar bugs to the ones here >> -- the best approximation of 18.2 is (supposed to be) used, but the system >> is not informed about the enormous error in this approximation and still >> thinks that 10 Hz is used. > > Does it suggest that we simply need to place lower limit of 128 on > lapic_timer_hz and lower limit of 18 on i8254 timer? As far as I understand > timer frequency could be higher than actual HZ (at least lapic code suggest > that it can). Will it help or cause any other issues? I use 100 for the minimum stathz but wouldn't want it to be much lower than that. I've tried much lower values (10 or 20) and noticed that this mainly makes statistics fairly innacurate, as you might expect (e.g., 180 seconds sys time for makeworld might become 160 or 200). SCHED_4BSD requires stathz to be about 128 but doesn't need this and can survive with weird values of stathz. The limit for i8254 should be 19 if anything, since the actual limit of 18.2 is not supported and the error between 18 and 18.2 is relatively large. Due to the nature of the interface, any frequency >= 18.2 can be represented precisely (more precisely at low frequencies), but there is no simple way to get anything lower than 18.2. I don't like such limits in general since they mainly get in the way of trying unusual configurations which should be under control of the user, but here they may be machine-generated. For emulation, I think you don't want lapic_timer_hz to be large any more than stathz or the i8254 interrupt frequency. The emulator might not like interrupting at a high rate, irrespective of the interrupt source, depending on how much it does in software for each type of source. So lapic_timer_hz = hz = stathz = ~100 might be best. (Once we have interrupted at 100 Hz, there we can use this for hz at no extra cost in the emulator). Also, since the lapic timer is more complicated than the i8254 timer, interrupts on it might be more expensive, so using lapic_timer might be a pessimization, except it normally reduces the number of interrupt sources. But use of the RTC can be avoided too. Bruce