Bill Holler wrote: > Madhavan Venkataraman wrote: >> Li, Aubrey wrote: >>> <Again, plain text please> >>> >>> >>>> I have provided two new API functions for callouts. >>>> >>> >>> >>>> - timeout_roundup() >>>> - realtime_timeout_roundup() >>>> >>> >>> >>>> These functions take an additional argument - number of >>>> ticks to roundup to. Using this, clients of the >>>> callout subsystem can request that their timers expire >>>> at specific boundaries. E.g., for TCP timers, we only >>>> need 10 ms granularity, not 1ms. So, if the clock >>>> resolution is set to hi, then TCP does not get affected >>>> by this as the TCP timers will work like in low >>>> resolution. They will get batched at 10 ms boundaries. >>>> >>> >>> >>>> Conceivably, clients can use these new interfaces to >>>> specify that their timers expire only at second >>>> boundaries or 100 ms boundaries and so forth. >>>> >>> >>> More clear. We don't care exactly when timers to happen for many >>> clients. So my quick thoughts is >>> >>> if timeout_roundup(1s), it's ok, let it be fired at the next 1s. >>> if timeout_roundup(10ms), can we fire it at the next 1s? >>> similarly, if timeout_roundup(900ms), move it to next 1 second. >>> >>> So previously CPU could be waken up 100 times in 1 second, >>> now it will only be waken up 1 time in 1 second(ignore realtime case). >>> >>> maybe 1 time 1 second is not acceptable. We can group these timers. >>> Let them happen in >>> 1) 0~100ms >>> and 2) 900ms~1s >>> Or 3 or 4 groups if needed. So CPU can sleep longer.(800ms) >>> Does this make sense? >>> >>> >>>> That said, the changes have to be made in the clients >>>> because this is a client specific thing. I am very very >>>> reluctant to change the behavior of the callout >>>> subsystem so that it batches things unbenounced to >>>> the clients. This will most probably lead to >>>> escalations against the subsystem. >>>> >>> I understood, bind callout subsystem with client is not a good idea. >>> So how about change the client? Is it possible? how many clients in >>> the current kernel implementation? let me guess, <1000? :-) >>> >>> Thanks, >>> -Aubrey >>> >> The two major clients of callouts are: >> >> 1. TCP >> 2. Condition Variable module >> >> We cannot align callouts to 1s in the above cases. The other cases >> are just drivers and some kernel modules like the memory scrubber. >> Not too many of them in comparison with the 2 cases I mention >> above. And even in these cases, the intervals tend to be in terms >> of seconds. So, I don't see much opportunity for batching callouts >> at one second boundaries. >> >> Madhavan > > > Are all callouts of the same interval/granularity batched together? > For example if there is a TCP callout with 10ms interval and > a usb callout with 10ms granularity, can there be just one 10ms > callout which processos both? > There is one callout for each. But the callouts are batched at 10 ms granularity. We cannot have a single callout because each caller of timeout() needs to be able to cancel a timeout if needed. For this reason, a callout ID is returned to the caller.
> I should probably wait for the webrev & design doc before > asking more questions. ;-) > > Thank you, > Bill > > P.S. Thunderbird can disable html email to just "intel.com" > by adding intel.com in the "Plain Text Tab" at: > edit->preferences :: composition->Send Options > ;-)
