Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932465AbVKMLJd (ORCPT ); Sun, 13 Nov 2005 06:09:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932473AbVKMLJc (ORCPT ); Sun, 13 Nov 2005 06:09:32 -0500 Received: from mx1.suse.de ([195.135.220.2]:13280 "EHLO mx1.suse.de") by vger.kernel.org with ESMTP id S932465AbVKMLJc (ORCPT ); Sun, 13 Nov 2005 06:09:32 -0500 From: Andi Kleen To: Ingo Molnar Subject: Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10) Date: Sun, 13 Nov 2005 11:53:24 +0100 User-Agent: KMail/1.8.2 Cc: john stultz , Darren Hart , Nishanth Aravamudan , Frank Sorenson , George Anzinger , Roman Zippel , Ulrich Windl , Thomas Gleixner , linux-kernel@vger.kernel.org References: <20051112044850.8240.91581.sendpatchset@cog.beaverton.ibm.com> <20051113073228.GA31468@elte.hu> In-Reply-To: <20051113073228.GA31468@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511131153.25978.ak@suse.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1902 Lines: 38 On Sunday 13 November 2005 08:32, Ingo Molnar wrote: > 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'.] Both noidletick and the per cpu gettimeofday change significantly how timer interrupts work. I hope your generalizations will be still compatible to that. It's a bit dangerous to generalize before things have their final shape. Also vsyscalls make it all more difficult, because they don't map very well to any kind of "timer drivers". > 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 :-) My point was basically that there is a lot of feature work going on on x86-64 in this area, and that has priority over any "cleanups" like this from my side. If it has settled again later maybe it can be generalized, or maybe not. I will only do it if it truly makes the code cleaner in the end, just lots of indirect pointers by itself isn't necessarily something that does this. -Andi - 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/