From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Zick" Subject: Re: Dynamic configure max_cstate Date: Fri, 31 Jul 2009 09:56:33 -0500 Message-ID: <200907310956.53816.lkml@morethan.org> References: <20090727073338.GA12669@rhlx01.hs-esslingen.de> <20090731080728.GA25049@rhlx01.hs-esslingen.de> <87prbg3ohq.fsf@basil.nowhere.org> Reply-To: lkml@MoreThan.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87prbg3ohq.fsf@basil.nowhere.org> Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org To: Andi Kleen Cc: "Zhang, Yanmin" , Robert Hancock , Corrado Zoccolo , LKML , linux-acpi@vger.kernel.org, venkatesh.pallipadi@intel.com List-Id: linux-acpi@vger.kernel.org On Fri July 31 2009, Andi Kleen wrote: > Andreas Mohr writes: > > > Instead we should strive for a far-reaching _generic_ mechanism > > which gathers average latencies of various I/O activities/devices > > and then uses some formula to determine the maximum (not necessarily ACPI) > > idle latency that we're willing to endure (e.g. average device I/O reply latency > > divided by 10 or so). > > The interrupt heuristics in the menu cpuidle governour are already > attempting this, based on interrupt rates (or rather > wakeup rates) which are supposed to roughly correspond with IO rates > and scheduling events together. > > Apparently that doesn't work in this case. The challenge would > be to find out why and improve the menu algorithm to deal with it. > I doubt a completely new mechanism is needed or makes sense. > > > And in addition to this, we should also take into account (read: skip) > > any idle states which kill busmaster DMA completely > > (in case of busmaster DMA I/O activities, that is) > > This is already done. > Almost - the VIA C7-M needs a bit of kernel command line help - - But should be easily fixable when I or one of the VIA support people GATI. (Bus snoops are only fully supported in C0 and C1 but idle=halt takes care of that.) Mike > -Andi