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?
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
;-)
