From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: interrupt latency while resuming. Date: Mon, 10 Jan 2011 21:11:50 -0800 Message-ID: <4D2BE696.80000@codeaurora.org> References: <4D2897D1.3040609@codeaurora.org> <20110108171332.GB31708@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from wolverine01.qualcomm.com ([199.106.114.254]:45153 "EHLO wolverine01.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750765Ab1AKFLv (ORCPT ); Tue, 11 Jan 2011 00:11:51 -0500 In-Reply-To: <20110108171332.GB31708@n2100.arm.linux.org.uk> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Russell King - ARM Linux Cc: Abhijeet Dharmapurikar , tglx@linutronix.de, "Rafael J. Wysocki" , Andrew Morton , Greg Kroah-Hartman , Alan Stern , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org On 01/08/2011 09:13 AM, Russell King - ARM Linux wrote: > > We know it takes something like 200ms to run the lpg calibration, and > this is responsible for the majority of the time when bringing a CPU > online. > > One solution is to sort out whether we need to re-run the lpj calibration > each time we resume a CPU. At the moment, we're just using the boot CPU > loops_per_jiffy for every udelay(), assuming that all CPUs are running > at the same clock rate - so we _could_ skip the calibration as its > never used. > > Or we could fix things so that it is used (which also sorts udelay for > asymetrically clocked secondary CPUs) but then we always have to re-run > the calibration, or we have to stipulate that secondary CPUs come up at > the same clock rate as they went down. I suspect there's systems out > there where the latter is not true at present, so it's not something we > can impose - which means we're stuck having to do 200ms of recalibration > per CPU. We're actually using a timer based udelay() (which uses calibrate_delay_direct() instead of the more expensive delay loop) and thus lpj is calculated in about 50ms. You raise an interesting point though since we don't need to recalibrate as our timesource is constant. It would be great to skip the recalibration in such a situation and speed up onlining CPUs. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.