Date: Wed, 04 Dec 2013 17:02:33 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Bret Ketchum <bcketchum@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Subject: Re: 9.1 callout behavior Message-ID: <529F4409.9080403@FreeBSD.org> In-Reply-To: <CAGm6yaRRcS1e5b_uo4wq=ArSMxFuuTkrKTgOTcQC9nbLnYi6Yw@mail.gmail.com> References: <CAGm6yaTEFECTYVb94A13TaXMPSLtKLpTbw4iNdgd8SuNF1QDaA@mail.gmail.com> <CAJ-Vmokrchy4pXLvZ21sCV09fQUdYKeUYCEH1U1NdfDBxhyJQg@mail.gmail.com> <5295A261.2060403@FreeBSD.org> <CAGm6yaRAPoiVXuv3HgvJCHBTUYGokLyRLb_n0MQEyRp%2BcJUrqA@mail.gmail.com> <CAGm6yaRRcS1e5b_uo4wq=ArSMxFuuTkrKTgOTcQC9nbLnYi6Yw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04.12.2013 14:49, Bret Ketchum wrote: > See attached. I've tightened up the definition of inconsistent > callout calls. A "Whoops" message indicates the callout function was > called either side of a 10ms window than what was expected. "Ouch" > indicates the cyclecounter does not agree with the expected period given > the same 10ms fudge factor. I have this module running on two of my tests systems with stable/9 (2xE5645 and i7-3770) and half hour later I see no any of related messages on consoles. Could you share what exactly do you have there logged? > On Wed, Nov 27, 2013 at 3:28 AM, Bret Ketchum <bcketchum@gmail.com > <mailto:bcketchum@gmail.com>> wrote: > > Alexander, > > In this scenario, global ticks should have increased by 100 > every interval. When the wheels go off the truck, global ticks will > be 800+ yet only a fraction of usual number of clock cycles have > increased. > > I'll try to cook up an kernel module which will reproduce. > > > On Wed, Nov 27, 2013 at 1:42 AM, Alexander Motin <mav@freebsd.org > <mailto:mav@freebsd.org>> wrote: > > Hi, Brett, > > Could you tell more about "ticks has increased 8x"? Tickless > mode it is somewhat tricky algorithm to track global ticks > counter, but it should not jump that big. Jumps there could > easily trigger wrong callout behavior in 9 (in 10 callout code > was rewritten and no longer depend on ticks). > > > On 21.11.2013 22:19, Adrian Chadd wrote: > > It sounds like you may have found an interesting test case. > > Mav, any ideas? > > On 21 November 2013 05:20, Bret Ketchum <bcketchum@gmail.com > <mailto:bcketchum@gmail.com>> wrote: > > I've a callout which runs every 100ms and does a > bit of accounting > using the global ticks variable. This one-shot callout > was called fairly > consistently in 8.1, every 100ms give or take a few > thousand clocks. I've > recently upgraded to 9.1 and for the most part the > period is consistent. > However, periodically the callout function is executed > anywhere between 5ms > to 20ms after the callout was reset and the function > returned while global > ticks has increased 8x. The hardware has not changed > (using the same > timecounter configuration): > > CPU: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz > (2500.05-MHz K8-class CPU) > > kern.timecounter.hardware: TSC-low > kern.timecounter.tick: 1 > kern.timecounter.invariant___tsc: 1 > kern.timecounter.smp_tsc: 1 > > And default eventtimer configuration: > > kern.eventtimer.singlemul: 2 > kern.eventtimer.idletick: 0 > kern.eventtimer.activetick: 1 > kern.eventtimer.timer: LAPIC > kern.eventtimer.periodic: 0 > > If tickless mode is disabled the inconsistency > goes away. Is the > premature expiration of the callout expected? Is the > jump in global ticks > typical (say from 100 ticks to 800 ticks in 1.5ms)? > > Bret > _________________________________________________ > freebsd-hackers@freebsd.org > <mailto:freebsd-hackers@freebsd.org> mailing list > http://lists.freebsd.org/__mailman/listinfo/freebsd-__hackers > <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>; > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@__freebsd.org > <mailto:freebsd-hackers-unsubscribe@freebsd.org>" > > > > -- > Alexander Motin > > > -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?529F4409.9080403>