lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ