Re: One-shot-oriented event timers management

Gary Jennejohn wrote:
> On Mon, 30 Aug 2010 12:11:48 +0200
> Gary Jennejohn <gljennjohn_at_googlemail.com> wrote:
> 
>> On Mon, 30 Aug 2010 13:07:38 +0300
>> Alexander Motin <mav_at_FreeBSD.org> wrote:
>>
>>> Gary Jennejohn wrote:
>>>> Hmm.  I applied your patches and am now running the new kernel.  But I
>>>> only installed the new kernel and didn't do make buildworld installworld.
>>>>
>>>> Mu systat -vm 1 doesn't look anything like yours.  I'm seeing about 2300
>>>> interrupts per second and most of those are coming from the hpet timers:
>>>>
>>>> 1122 hpet0:t0
>>>> 1124 hpet0:t1
>>> It means 1000Hz of hardclock (hz) events mixed with 127Hz of statclock
>>> (stathz) events. HPET timer here works in one-shot mode handling it.
>>>
>>>> So, what else did you do to reduce interrupts so much?
>>>>
>>>> Ah, I think I see it now.  My desktop has only C1 enabled.  Is that it?
>>>> Unfortunately, it appears that only C1 is supported :(
>>> Yes, as I have said, at this moment empty ticks skipped only while CPU
>>> is in C2/C3 states. In C1 state there is no way to handle lost events on
>>> wake up. While it may be not very dangerous, it is not very good.
>>>
>> Too bad.  I'd say that systems which are limited to C1 don't benefit
>> much (or not at all) from your changes.
>>
> 
> OK, this is purely anecdotal, but I'll report it anyway.
> 
> I was running pretty much all day with the patched kernel and things
> seemed to be working quite well.
> 
> Then, after about 7 hours, everything just stopped.
> 
> I had gkrellm running and noticed that it updated only when I moved the
> mouse.
> 
> This behavior leads me to suspect that the timer interrupts had stopped
> working and the mouse interrupts were causing processes to get scheduled.
> 
> Unfortunately, I wasn't able to get a dump and had to hit reset to
> recover.
> 
> As I wrote above, this is only anecdotal, but I've never seen anything
> like this before applying the patches.

One-shot timers have one weak side: if for some reason timer interrupt
getting lost -- there will be nobody to reload the timer. Such cases
probably will require special attention. Same funny situation with
mouse-driven scheduler happens also if LAPIC timer dies when pre-Core-iX
CPU goes to C3 state.

-- 
Alexander Motin