Re: [RFC PATCH] hrtimer: removing all ur callback modes

[Oliver Hartkopp <oliver@hartkopp.net>]

Peter Zijlstra wrote:
> On Sun, 2008-12-07 at 13:59 +0100, Oliver Hartkopp wrote:
>   
>>>
>>>> On Tue, 2008-11-25 at 12:43 +0100, Peter Zijlstra wrote:
>>>>  
>>>>         
>>>>> Hi,
>>>>>
>>>>> This is an attempt at removing some of the hrtimer complexity by
>>>>> reducing the number of callback modes to 1.
>>>>>
>>>>> This means that all hrtimer callback functions will be ran from 
>>>>> HARD-irq
>>>>> context.
>>>>>
>>>>> I went through all the 30 odd hrtimer callback functions in the kernel
>>>>> and saw only one that I'm not quite sure of, which is the one in
>>>>> net/can/bcm.c - hence I'm CC-ing the folks responsible for that code.
>>>>>     
>>>>>           
>>>
>> Hi Peter,
>>
>> i ran a heavy load test, which get's (reproducible) the attached outputs ...
>>
>> Maybe it's not that good to define the hrtimer context to be always 
>> hard-irq.
>>     
>
> Thing is, this 'cleanup' removes quite a bit of complexity from the core
> hrtimer code, and afaict your bit is the only thing that cannot seem to
> cope. So I'd rather look at fixing your site than re-introduce softirqs
> to hrtimers.
>   

Hrtimers looked an excellent approach to have high resolution timers in 
the Kernel when i moved from the low resolution jiffies to hrtimers - 
also to use the latest timer infrastructure. So why is the removal of 
already used functionality (e.g. to use sock_queue_rcv_skb() from a 
hrtimer callback) a so called 'cleanup' ??

Hrtimers are excellent stuff for timing requirements below 500ns. I use 
them for that reason and i can't see the real benefit of your cleanup.

The current hrtimer code is settled, does exactly what is expected and 
gives an upgrade path from other timer infrastructures if you need 
higher resolutions. That's the way it should be and the way it was 
obviously designed by Thomas.

So your functionality reduction unfortunately get's a NACK from me ... 
sorry.

Best regards,
Oliver