Date: Tue, 31 Aug 2010 10:29:18 +0200 From: Gary Jennejohn <gljennjohn@googlemail.com> To: gljennjohn@googlemail.com Cc: freebsd-hackers@freebsd.org, Alexander Motin <mav@FreeBSD.org>, FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: One-shot-oriented event timers management Message-ID: <20100831102918.4f5404cc@ernst.jennejohn.org> In-Reply-To: <20100830121148.11926306@ernst.jennejohn.org> References: <4C7A5C28.1090904@FreeBSD.org> <20100830110932.23425932@ernst.jennejohn.org> <4C7B82EA.2040104@FreeBSD.org> <20100830121148.11926306@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Aug 2010 12:11:48 +0200 Gary Jennejohn <gljennjohn@googlemail.com> wrote: > On Mon, 30 Aug 2010 13:07:38 +0300 > Alexander Motin <mav@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. -- Gary Jennejohn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100831102918.4f5404cc>