Gary Jennejohn wrote: > On Mon, 30 Aug 2010 12:11:48 +0200 > Gary Jennejohn <gljennj...@googlemail.com> wrote: > >> On Mon, 30 Aug 2010 13:07:38 +0300 >> Alexander Motin <m...@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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
