<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
