From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755094AbdJIQf7 (ORCPT ); Mon, 9 Oct 2017 12:35:59 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:25820 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754357AbdJIQf6 (ORCPT ); Mon, 9 Oct 2017 12:35:58 -0400 Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot To: Peter Zijlstra Cc: linux@armlinux.org.uk, schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com, john.stultz@linaro.org, sboyd@codeaurora.org, x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, douly.fnst@cn.fujitsu.com 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> From: Pavel Tatashin Message-ID: Date: Mon, 9 Oct 2017 12:34:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170927125857.yvwefpejzskiduwu@hirez.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > Urgh, that's horrific. > > Can't we simply make sched_clock() go earlier? (we're violating "notsc" > in any case and really should kill that option). > > Then we can do something like so on top... > Hi Peter, I've been thinking about your proposal, and I have one concern: sched_clock() can be implemented two ways either via pv_time_ops.sched_clock vectors when CONFIG_PARAVIRT is defined sched_clock() paravirt_sched_clock() PVOP_CALL0(unsigned long long, pv_time_ops.sched_clock); Or native via alias sched_clock() native_sched_clock() Using sched_clock_early() approach makes early time stamps work with both cases when it is determined that tsc can be used simple_udelay_calibration(). (As we agreed I am going to change notsc to use tsc=unstable path.) It may be not the most efficient clock for some virtualizations to use rdtsc directly, but since this is for early boot only, and not something that is going to be used after machine is booted it is OK. Pavel