[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <493CFE3E.7080200@hartkopp.net>
Date: Mon, 08 Dec 2008 12:00:14 +0100
From: Oliver Hartkopp <oliver@...tkopp.net>
To: Peter Zijlstra <peterz@...radead.org>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
linux-kernel <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC PATCH] hrtimer: removing all ur callback modes
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists