Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932133AbVKMHce (ORCPT ); Sun, 13 Nov 2005 02:32:34 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932166AbVKMHce (ORCPT ); Sun, 13 Nov 2005 02:32:34 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:53446 "EHLO mx3.mail.elte.hu") by vger.kernel.org with ESMTP id S932133AbVKMHce (ORCPT ); Sun, 13 Nov 2005 02:32:34 -0500 Date: Sun, 13 Nov 2005 08:32:28 +0100 From: Ingo Molnar To: Andi Kleen Cc: john stultz , Darren Hart , Nishanth Aravamudan , Frank Sorenson , George Anzinger , Roman Zippel , Ulrich Windl , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10) Message-ID: <20051113073228.GA31468@elte.hu> References: <20051112044850.8240.91581.sendpatchset@cog.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: 0.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.0 required=5.9 tests=AWL autolearn=disabled SpamAssassin version=3.0.3 0.0 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1688 Lines: 34 * Andi Kleen wrote: > At least on x86-64 there is currently so much other timer related > development going on (per CPU TSC timers, no idle tick, 64bit HPET > etc.) that I don't want any x86-64 bits of that merged for the next > time. The other stuff needs to settle first. > > I haven't read the patchset in full detail, but from a quick look it's > also not obvious too me in which way it is easier and cleaner than the > old setup. While the old code was quirky in parts the new one seems to > fall more in the overmodularization/too many indirect callbacks trap. there are 3 "generic" components needed right now to clean up all time related stuff: GTOD, ktimers and clockevents. [you know the first two, and clockevents is new code from Thomas Gleixner that generalizes timer interrupts and introduces one compact notion for 'clock chips'.] what is the point? Ontop of these, a previously difficult feature, High Resolution Timers became _massively_ simpler. All of these patches exist together in the -rt tree, so it's not handwaving. The same will be the case for idle ticks / dynamic ticks [we started with HRT because it is so much harder than idle ticks]. So i do agree with you that GTOD needs more work, but it also makes time related features all that much easier. right now it's GTOD that needs the most work before it can be merged upstream, so you picked the right one to criticise :-) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/