Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031233AbWI0XNS (ORCPT ); Wed, 27 Sep 2006 19:13:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1031234AbWI0XNS (ORCPT ); Wed, 27 Sep 2006 19:13:18 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:45710 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S1031233AbWI0XNQ (ORCPT ); Wed, 27 Sep 2006 19:13:16 -0400 Subject: Re: [RFC] exponential update_wall_time From: john stultz To: Roman Zippel Cc: lkml , Ingo Molnar , Thomas Gleixner , Andrew Morton In-Reply-To: References: <1159385734.29040.9.camel@localhost> Content-Type: text/plain Date: Wed, 27 Sep 2006 16:13:12 -0700 Message-Id: <1159398793.7297.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1573 Lines: 42 On Thu, 2006-09-28 at 01:04 +0200, Roman Zippel wrote: > On Wed, 27 Sep 2006, john stultz wrote: > > > Accumulate time in update_wall_time exponentially. > > This avoids long running loops seen with the dynticks patch > > as well as the problematic hang" seen on systems with broken > > clocksources. > > This is the wrong approach, second_overflow() should be called every HZ > increment steps and your patch breaks this. First, forgive me, since I've got a bit of a head cold, so I'm even slower then usual. I just don't see how this patch changes the behavior. Every second we will call second_overflow. But in the case where we skipped 100 ticks, we don't loop 100 times. Could you explain this a bit more? > There are other approaches oo accommodate dyntick. > 1. You could make HZ in ntp_update_frequency() dynamic and thus reduce the > frequency with which update_wall_time() needs to be called (Note that > other clock variables like cycle_interval have to be adjusted as well). I'm not sure how this is functionally different from what this patch does. > 2. If dynticks stops the timer interrupt for a long time, it could > precalculate a few things, e.g. it could complete the second and then > advance the time in full seconds. Not following this one at all. Again, sorry for being so thick. -john - 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/