linux-kernel - Re: [patch 00/21] Highres / dynticks drop in replacement for 2.6.19-rc5-mm1

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:	Thu, 23 Nov 2006 23:24:13 +0100 (CET)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Andrew Morton <akpm@...l.org>, LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, Len Brown <lenb@...nel.org>,
	John Stultz <johnstul@...ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Andi Kleen <ak@...e.de>
Subject: Re: [patch 00/21] Highres / dynticks drop in replacement for
 2.6.19-rc5-mm1

Hi,

On Thu, 9 Nov 2006, Thomas Gleixner wrote:

> Andrew,
> 
> this is a drop in replacement for the following patches in 2.6.19-rc5-mm1:
> 
> hrtimers-state-tracking.patch
> up to
> acpi-verify-lapic-timer-fix.patch

There is still the gtod-exponential-update_wall_time patch before that, I 
explained previously why it's wrong and how to fix this properly. Andrew, 
please drop this one.

http://www.ussg.iu.edu/hypermail/linux/kernel/0609.3/1320.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0609.3/1303.html

Something I also wanted to mention about the OLS paper: It's an 
interesting read and answers a few question, but not all. It concentrates 
very much on the past (previous and current implementations), what I'm 
missing are more details on how it can be used in the future. IMO it's 
very important information regarding merging, i.e. how can this be applied 
to our various architectures. This is were have my doubts and more 
questions about it later.

The paper stresses the point that it provides a generic infrastructure, 
but as such it also brings some amazing complexities. Dedicated 
implementations often have the advantage to be simpler and faster (I'm not 
saying that current ones are). How does your implementation keep the 
source and runtime complexities under control? Such generic frameworks 
have the tendency to grow - new requirements have to be met and thus 
complexity further increases.

bye, Roman
-
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/