Madhavan Venkataraman wrote: > Liu, Jiang wrote: >> 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. >> > You cannot change the behavior of callouts for the sake > of power efficiency. It will mean that we introduce a delay > in each of the aggregated timers. This could screw up > drivers, TCP timers, etc. The maximum we can do is > to make sure that callouts are event driven as opposed > to polled (every tick) so that work is done by a CPU > only when there is a need.
Today callouts are dispatched from the clock tick? This effectively "batches" callouts to 10 ms intervals or whatever the clock interval is without problems.... Bill >> *From:* tesla-dev-bounces at opensolaris.org >> [mailto:tesla-dev-bounces at opensolaris.org] *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 >>> >> >
