Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4259113imm; Mon, 25 Jun 2018 12:27:25 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKWcCgmDjK0WddyGsDXiomtYhwQU5cBiaTEjOX0MsVG+rSymAqvqsTc/plDbsgYquLm/4xF X-Received: by 2002:a17:902:6903:: with SMTP id j3-v6mr13491637plk.313.1529954845157; Mon, 25 Jun 2018 12:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529954845; cv=none; d=google.com; s=arc-20160816; b=NGuzHo92+38uPCtfk1KB2E4i05kCEFSKVkwSJjPG/zT8CarAVORYbtxLmxrVsnfM+e vrk09G4tBtq4TjAa/YfzqRF5OKibT0L1VrAU2CK7yX+TVUv9oHHBsBypLwLxPUoJ2TBg QOZlotLspRly4BKddV11J1y3wppLaiDqFqD9/yqiub/jOpKcTvydEpraINpBKS3AY9qn fTkFpHfd0bPuzpfEFsgMFueeazIom/R6OhCTicW1Q/Qm+siNEb5eLRui+MIHrQDDvOTs 2xz2VaXLm8fiUOWZBJIWrOhi5YeLfMtJw22g9yo9FmR0r9VVo0Hbnjnl7en1ZIwLETvi RyKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=q21WXcY1Vn43MOQufiyNVkKtmEroZEECdYU+f/2cCNk=; b=0e/8rIF3mf7Z4Xy26ekAXLKmptnSYY14/Q+VMwGEZ5iZ83rQ+95NfCr7GhgJ660Svk rhp9bKcU7CyP6GLR+K4SODLmLBjUM8c6uF8OoiYjRZltM6mkQqukMXUS5NFz7QY+kn4Y /Hs5D4eibscEoF8Y3rdnQ3J/mXAZoMdbY1DhL6hmHzkHofflgqmA1ccNIAh7Cs7A2iVF xZJnFjqkkSdST150nY3c/D8nKUJyt0/Rc8C+2zI9riIJwm7gLdYEikNMb8Z6jXDGz5Gk pBmToJniNW0AwIBi8NWS0v3q2MXJn/vATG0kLIzJbdePJRAbdrI4CNTBXpdH83zzyVLT rA0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=eqrnWG1r; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b2-v6si14880643plz.118.2018.06.25.12.27.10; Mon, 25 Jun 2018 12:27:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=eqrnWG1r; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964884AbeFYT0a (ORCPT + 99 others); Mon, 25 Jun 2018 15:26:30 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:39900 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754532AbeFYT03 (ORCPT ); Mon, 25 Jun 2018 15:26:29 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w5PJEXdK060381; Mon, 25 Jun 2018 19:23:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2017-10-26; bh=q21WXcY1Vn43MOQufiyNVkKtmEroZEECdYU+f/2cCNk=; b=eqrnWG1r6YD61kOV4AAug2LC8on8+JXxTMrf4w8Gp0YwlB5Br3hUH96YCBKMUUEU5z/i 9Tw7BNvtPz+xS0JrU95yXDmVvSiL6Zu7lXW8rMv6GjWtBDs1/jzrfWcyme1ufHSynlrb EmhR3pq+X3jKi1NIqbcvaXrTW0FJrExk6xIsbLb75gaUyxaGU91KIC+RoIZFLuDXqF1J 4FdapfoaQCO9dFMS6Q9VrkL/WeyE5pAtHG6ldcqDuQAl3Y6u5QyW/XgWYOVd4Y6AmbEe 4puWAtHyeSdIjiIF3JKBBBY534t0RQXi8F4nseiso6dM8dBj7G6zrAPpvgMnBtqHZKUi eg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2ju1wfh825-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 Jun 2018 19:23:28 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w5PJNQvP000555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 Jun 2018 19:23:26 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w5PJNNDp004866; Mon, 25 Jun 2018 19:23:23 GMT Received: from xakep.localdomain (/73.69.118.222) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jun 2018 12:23:23 -0700 Date: Mon, 25 Jun 2018 15:23:20 -0400 From: Pavel Tatashin To: Peter Zijlstra Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, 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, prarit@redhat.com, feng.tang@intel.com, pmladek@suse.com, gnomes@lxorguk.ukuu.org.uk, linux-s390@vger.kernel.org Subject: Re: [PATCH v12 10/11] sched: early boot clock Message-ID: <20180625192320.kzmqkvmfh5aeuhhx@xakep.localdomain> References: <20180621212518.19914-1-pasha.tatashin@oracle.com> <20180621212518.19914-11-pasha.tatashin@oracle.com> <20180625085543.GT2494@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180625085543.GT2494@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20180622 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8935 signatures=668703 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806250220 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, I have revisted this patch after modifying x86 sched_clock() to contigously output tsc once it is setup early in boot, based on the latest suggestions from Thomas. On 18-06-25 10:55:43, Peter Zijlstra wrote: > On Thu, Jun 21, 2018 at 05:25:17PM -0400, Pavel Tatashin wrote: > > Allow sched_clock() to be used before schec_clock_init() and > > sched_clock_init_late() are called. This provides us with a way to get > > early boot timestamps on machines with unstable clocks. > > There are !x86 architectures that use this code and might not expect to > have their sched_clock() called quite that early. Please verify. > > > + local_irq_disable(); > > + __gtod_offset = sched_clock() + __sched_clock_offset - ktime_get_ns(); > > + local_irq_enable(); > > This might work in sched_clock_init(), which is pre-SMP. > > > sched_clock_running = 2; > > /* > > * Ensure that it is impossible to not do a static_key update. > > @@ -350,8 +355,9 @@ u64 sched_clock_cpu(int cpu) > > if (sched_clock_stable()) > > return sched_clock() + __sched_clock_offset; > > > > - if (unlikely(!sched_clock_running)) > > - return 0ull; > > + /* Use early clock until sched_clock_init_late() */ > > + if (unlikely(sched_clock_running < 2)) > > + return sched_clock() + __sched_clock_offset; > > And then this remains !sched_clock_running, except instead of 0, you > then return sched_clock() + __sched_clock_offset; > > > preempt_disable_notrace(); > > scd = cpu_sdc(cpu); Unfortunatly the above suggestion won't work. And here is why. We have a call sequence like this: start_kernel sched_init() sched_clock_init() In this call sched_clock_running is set to 1. Which means that sched_clock_cpu() starts doing the following sequence: scd = cpu_sdc(cpu); clock = sched_clock_local(scd); Where we try to filter the output of sched_clock() based on the value of scd. But, that won't work, because to get this functionality, we need to have: timer initialized that wakes up and updates scd, and we need timekeeping initialized, so we can call ktime_get_ns(). Both of which are called later. ... timekeeping_init() After this we can call ktime_get_ns() time_init() Here we configure x86_late_time_init pointer. ... late_time_init() x86_late_time_init() x86_init.timers.timer_init() hpet_time_init() Only after this call we finally start getting clock interrupts, and can get precise output from sched_clock_local(). The way I solved the above, is I changed sched_clock() to keep outputing time based on early boot sched_clock() until sched_clock_init_late(), at whic point everything is configured and we can switch to the permanent clock, eventhough this happens after smp init. If you have a better solution, please let me know. Thank you, Pavel