Maybe Aubrey means whether could we aggregate non-realtime timer to reduce CPU wakeups. For example, 100 non-realtime timers with 1-second interval may distribute as one trigger per 10ms, so could we aggregate these timers, say at the end of each second? I think delaying non-realtime timer is acceptable to improve power efficiency.
________________________________ From: tesla-dev-bounces at opensolaris.org [mailto:[email protected]] On Behalf Of Madhavan Venkataraman Sent: 2008?6?10? 14:23 To: Li, Aubrey Cc: Bill.Holler at Sun.COM; tesla-dev at opensolaris.org Subject: Re: [tesla-dev] callouts and cyclics with the new tickless work? Li, Aubrey wrote: Madhavan.Venkataraman wrote: Bill Holler wrote: Hi Tesla Dev, Where will callouts live in the tickless world? Will callouts become a "one shot" cyclic? cyclic_fire() currently reschedules each cyclic; it does not have "one shot" support. A prototype moves the next cyclic from one cpu to a different cpu to trigger cbe_fire() with a cross call. This is an alternative to using the HPET interrupt to trigger cbe_fire() on a deep C-state idle cpu when the local APIC is not working. A very small amount of code had to be added in cyclic_fire() to remove the "one time" cyclic from the remote cpu's cyclic heap after cyclic_retire() because there is no concept of a one-shot cyclic. I am currently working on the Tickless Callout stuff. Infact, it will be code complete in a week's time. I will provide your team with the latest design doc and webrev if you are interested. In the new design, callouts are maintained in a heap. There is one heap corresponding to each CPU. All timeouts issued from a CPU get queued in the CPUs heap. There is one cyclic per CPU for realtime callouts and one for normal callouts. The cyclic works off of the heap and picks the earliest one and programs itself. A new cyclic API function cyclic_reprogram() has been defined to allow reprogramming of a cyclic. The callout cyclic handlers use this function to reprogram their next expire. What will determine the callout next expire in tickless? will it be the same as the current implementation? Timeouts will be created using the existing APIs timeout() and realtime_timeout() as usual. These timeouts will be managed in per-CPU data structures. On each CPU, there will be two cyclics, one for realtime and one for normal callouts. When the cyclic fires, it will process expired timeouts in a fashion similar to the existing implementation. Then it will program itself to expire at the next earliest timeout. My changes also support one-shot timers (in effect). If the interval for a cyclic is specified as infinity (INT64_MAX), then the cyclic subsystem recognizes that and programs the cyclic to infinity. So, the cyclic drops to the bottom of the cyclic heap and just stays there. Of course, this is not a perfect one-shot. But removing one-shots from the cyclic heap and reinserting them is just extra overhead and does not seem warranted at this time. Currently callouts could happen at any time, so in a period, CPU can be waken up at any time. In tickless kernel, can we try to batch process the callouts of the same scheduling type and the same priority so that one interrupt can handle more callouts, that is, cpu can sleep longer. I am not sure what the question is here. So, I will forward the latest design doc and webrev as soon as they are ready. They might answer most of the questions people might have. If needed, I could present the design to the Tesla team, if people think that that might be a good idea. Madhavan Thanks, -Aubrey -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20080610/c59969f2/attachment.html>
