From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757429AbZBMJjs (ORCPT ); Fri, 13 Feb 2009 04:39:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751013AbZBMJjk (ORCPT ); Fri, 13 Feb 2009 04:39:40 -0500 Received: from www.tglx.de ([62.245.132.106]:40885 "EHLO www.tglx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750711AbZBMJjj (ORCPT ); Fri, 13 Feb 2009 04:39:39 -0500 Date: Fri, 13 Feb 2009 10:39:24 +0100 (CET) From: Thomas Gleixner To: Ingo Molnar cc: Michael Davidson , mbligh@google.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] clockevents: avoid unnecessary reprograming of event timer In-Reply-To: <20090213082223.GA4606@elte.hu> Message-ID: References: <20090212222326.394E121B187@localhost> <20090213082223.GA4606@elte.hu> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 13 Feb 2009, Ingo Molnar wrote: > > + if (ktime_equal(dev->next_event, expires)) > > + return 0; > > + > > Hm, given that a good high-res source has nanoseconds resolution, > what's the chance of this optimization triggering in practice? > Near zero i think - unless we trigger useless reprogramming without > having added or removed any new timers - but then we should > concentrate on analyzing the reason for that redundant reprogramming. > > Does it trigger often for you? The only point where this should trigger is when we come out of C2/C3 and switch the local APIC timer back on. There we reload the next_event which was discarded in the hardware before we entered C2/C3 and switched to the broadcast timer. So this change would prevent the rearming of the local APIC after coming out of C2/C3 and probably give us some new C-State related headaches. Thanks, tglx