Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753235AbdI0Nwq (ORCPT ); Wed, 27 Sep 2017 09:52:46 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:33214 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752974AbdI0Nwp (ORCPT ); Wed, 27 Sep 2017 09:52:45 -0400 X-IronPort-AV: E=Sophos;i="5.42,445,1500912000"; d="scan'208";a="28487370" Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot To: Pasha Tatashin , Peter Zijlstra References: <1504116205-355281-1-git-send-email-pasha.tatashin@oracle.com> <1504116205-355281-2-git-send-email-pasha.tatashin@oracle.com> <20170927125857.yvwefpejzskiduwu@hirez.programming.kicks-ass.net> <20170927131003.dxbvu7frcqgtiwaz@hirez.programming.kicks-ass.net> CC: , , , , , , , , , From: Dou Liyang Message-ID: <4a62156c-ea0f-749f-e21b-37919dfda1df@cn.fujitsu.com> Date: Wed, 27 Sep 2017 21:52:36 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 6274E46BA7AE.AB8D7 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1437 Lines: 47 Hi Pasha, Peter At 09/27/2017 09:16 PM, Pasha Tatashin wrote: > Hi Peter, > > I am totally happy with removing notsc. This certainly simplifies the > sched_clock code. Are there any issues with removing existing kernel > parameters that I should be aware of? > We do not want to do that. Because, we use "notsc" to support Dynamic Reconfiguration[1]. AFAIK, this feature enables hot-add system board which contains CPUs and memories. But the CPUs in different board may have different TSCs which are not consistent with the TSC from the existing CPUs. If we hot-add a board directly, the machine may happen the inconsistency of TSC. We make our effort to specify the same TSC value as existing one through hardware and firmware, but it is hard. So we recommend to specify "notsc" option in command line for users who want to use Dynamic Reconfiguration. [1] http://www.fujitsu.com/global/products/computing/servers/mission-critical/primequest/technology/availability/dynamic-reconfiguration.html Thanks, dou > Thank you, > Pasha > > On 09/27/2017 09:10 AM, Peter Zijlstra wrote: >> On Wed, Sep 27, 2017 at 02:58:57PM +0200, Peter Zijlstra wrote: >>> (we're violating "notsc" in any case and really should kill that >>> option). >> >> Something like so; in particular simple_udelay_calibrate() will issue >> RDTSC _way_ early, so there is absolutely no point in then pretending we >> can't use RDTSC for sched_clock. >> > > >