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? > > 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. Thanks, -Aubrey
