svn commit: r184293 - in head/sys: amd64/amd64 i386/i386

[Bruce Evans]

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