Right, batch process these callouts will reduce the interrupt times and hence
reduce CPU wakeup times.
So we can get more power saving.
Do this make sense?
Looking forward to your design docs.
-Aubrey
________________________________
From: Liu, Jiang
Sent: Tuesday, June 10, 2008 2:31 PM
To: Madhavan.Venkataraman at Sun.COM; 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?
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: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20080610/51f61fac/attachment.html>
