Date: Wed, 01 Sep 2010 15:21:41 +0300 From: Alexander Motin <mav@FreeBSD.org> To: gljennjohn@googlemail.com Cc: freebsd-hackers@freebsd.org, FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: One-shot-oriented event timers management Message-ID: <4C7E4555.3000802@FreeBSD.org> In-Reply-To: <20100901141541.3e36c868@ernst.jennejohn.org> References: <4C7A5C28.1090904@FreeBSD.org> <20100830110932.23425932@ernst.jennejohn.org> <4C7B82EA.2040104@FreeBSD.org> <20100830121148.11926306@ernst.jennejohn.org> <20100831102918.4f5404cc@ernst.jennejohn.org> <4C7CC1DE.1080907@FreeBSD.org> <4C7E2E8A.3030709@FreeBSD.org> <20100901141541.3e36c868@ernst.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary Jennejohn wrote: > On Wed, 01 Sep 2010 13:44:26 +0300 > Alexander Motin <mav@FreeBSD.org> wrote: >> I have reproduced the problem locally. It happens more often when ticks >> are not stopped on idle, like in your original case (or if explicitly >> enabled by kern.eventtimer.idletick sysctl). >> >> I've made some changes to HPET driver, which, I hope, should fix >> interrupt losses there. >> >> Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch >> >> Patch also includes some optimizations to reduce lock contention. >> >> Thanks for testing. > > OK, I'll give it a try, althought your previous patch seems to be working > quite well. Stopping/starting timer around idle could partially hide the problem. Single external even in such case could be enough to revive system. > BTW I've also been using tm6292_idle.patch. Do I really need it? It is not necessary. It just reduces number of events generated by system by hacking several aggressive places I've found. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C7E4555.3000802>