Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752195AbdI0SLx (ORCPT ); Wed, 27 Sep 2017 14:11:53 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:43407 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751016AbdI0SLw (ORCPT ); Wed, 27 Sep 2017 14:11:52 -0400 Date: Wed, 27 Sep 2017 20:11:40 +0200 From: Peter Zijlstra To: Russell King - ARM Linux Cc: Pavel Tatashin , 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 Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot Message-ID: <20170927181140.GN17526@worktop.programming.kicks-ass.net> References: <1504116205-355281-1-git-send-email-pasha.tatashin@oracle.com> <1504116205-355281-2-git-send-email-pasha.tatashin@oracle.com> <20170927144506.GU20805@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170927144506.GU20805@n2100.armlinux.org.uk> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1099 Lines: 19 On Wed, Sep 27, 2017 at 03:45:06PM +0100, Russell King - ARM Linux wrote: > On Wed, Aug 30, 2017 at 02:03:22PM -0400, Pavel Tatashin wrote: > > In Linux printk() can output timestamps next to every line. This is very > > useful for tracking regressions, and finding places that can be optimized. > > However, the timestamps are available only later in boot. On smaller > > machines it is insignificant amount of time, but on larger it can be many > > seconds or even minutes into the boot process. > > The sched_clock work I did for ARM could be setup really early at boot, > from setup_arch(). I tried to encourage platforms to do that, but all > my encouragement fell on deaf ears - most people setup the sched_clock > source along side the time initialisation on ARM. > > I don't think we need yet another "early" mechanism to solve this problem, > we just need people to use the existing mechanism to register their > sched_clock implementation earlier. x86 is a bit 'special' in the whole sched_clock department. But yes, we should very much make the regular sched_clock() happen earlier.