One-shot-oriented event timers management
gljennjohn at googlemail.com
Tue Aug 31 08:29:22 UTC 2010
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
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
As I wrote above, this is only anecdotal, but I've never seen anything
like this before applying the patches.
More information about the freebsd-hackers