Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp5470856imm; Tue, 19 Jun 2018 10:52:47 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJbiXyvgcOjLrxxlitWExZgPtEbSBhkJQhhBi49U8f0T49yY5VpjrXqPO4VFyexiHIPcebq X-Received: by 2002:a17:902:8b8c:: with SMTP id ay12-v6mr19896952plb.74.1529430767268; Tue, 19 Jun 2018 10:52:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529430767; cv=none; d=google.com; s=arc-20160816; b=R3gmIq72hkoeCAu1PgkHZt+dAdpxSZD5iLb/fSdaHQKOyWP6VsNtJAwt7TIQN7QNGd 9UtsLXfviGB8pD6/vzxllw3XteiuDc062DZmhgU3IQoJcHf+i9UP5JLP6NuqD38TidJH z2pvVKnN4FNF42sIpMrt+553D1aJe+vY4WfUnV/OzWVh0XdABTSROAytRDyT+dSUTUWX GgiqOAAmx9SUxvJLBGnL5cFx2KAd7HwQaCGuv/8cnxE440VVryIzVikiAQpZ+lECRfIf Eq3NyjnNqtfJ1gxBbCY0if4XXbj5GnGKvtaBeknYk07RKAJr9AWHpf7eCmf5FUtwA14r TlFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=L1Y3aJMaADaRYY5Ax3UX3WVKcoiEsPEuWCNs0cTsN2E=; b=ebMMSFObuMnr7fua/YuE0NgiKQdDkdCl9FZlIHAsVJR84sRlodM+bJnKr4eMMwqgCt EoRC7v9yzSRzHPaa3zGEJQqh1trT5+djsU6fzUOHSPcRWe+ubmVkz+//3l+SwaWqvNDR nMVTUAN9kJ3BlOf46GUt7NIFOPUOrpANOvo4BqSNTwkjXI5XTlEWXO+Pj+9bzGj/COUP Y9B+qJ32cXBc5q638l19DosjW0aA77ohR7GAdZIS6dlFF3Vac49O/1GW/0zMzz5EW5ze i0rUAVJHD2s947jES2mR1sbXu9oN47HaI29f9JX7Ict9CrnqCKnvEocebG4CmPaxdYFr TIQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=iyqgjHAE; 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 d10-v6si173965pgo.630.2018.06.19.10.52.33; Tue, 19 Jun 2018 10:52:47 -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=iyqgjHAE; 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 S1030426AbeFSRvf (ORCPT + 99 others); Tue, 19 Jun 2018 13:51:35 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:60348 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966706AbeFSRve (ORCPT ); Tue, 19 Jun 2018 13:51:34 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w5JHmauo071608 for ; Tue, 19 Jun 2018 17:51:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp-2017-10-26; bh=L1Y3aJMaADaRYY5Ax3UX3WVKcoiEsPEuWCNs0cTsN2E=; b=iyqgjHAEqNHsBSKQDEJMFu37TDOp6VvvOl2PHIwdKW1kxsfmUSoJqTUFRSpYQy5VUswE 0YbbsLQckOiGI71ZzMaZDGRjijUHLm5Z1Jm5FpSpETaLZYWQiEzjYFqgaWYvpElwE+bY dBOasXh+SMk8KbxxPT1/UCQhvfvaiIPuV4Onv+JYiIIkBKd8WBgHyJdZoBhF6SZnGq6N U8WN7Rgpgnqz9++ag8fKRy6DVkv39rcK8P6FaFbvYyKOEim18/uZgs694/B/ZwYzsFIk YLxReGTr9F/mbFLauyV4AXFsUZCl0w5mTrLKYQxjsqJsG2hwcJs03EJI2bzEoCjeHIp/ gw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2jmt01hase-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 19 Jun 2018 17:51:33 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w5JHpV6g024856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 19 Jun 2018 17:51:31 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w5JHpVXg027812 for ; Tue, 19 Jun 2018 17:51:31 GMT Received: from mail-ot0-f179.google.com (/74.125.82.179) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Jun 2018 10:51:30 -0700 Received: by mail-ot0-f179.google.com with SMTP id d19-v6so634989oti.8 for ; Tue, 19 Jun 2018 10:51:30 -0700 (PDT) X-Gm-Message-State: APt69E08YmvERHzaJ5Q83PEC+VwT3ABRwOOv9SucfaEgR2LfG40k0/QN 6BYYShn4CBJnnIT/ASxuB9ECLdyVFOqlSMQ2FUU= X-Received: by 2002:a9d:4609:: with SMTP id y9-v6mr10048311ote.259.1529430690299; Tue, 19 Jun 2018 10:51:30 -0700 (PDT) MIME-Version: 1.0 References: <20180615174204.30581-1-pasha.tatashin@oracle.com> <20180615174204.30581-2-pasha.tatashin@oracle.com> In-Reply-To: From: Pavel Tatashin Date: Tue, 19 Jun 2018 13:50:54 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v10 1/7] x86/tsc: remove tsc_disabled flag To: tglx@linutronix.de Cc: Steven Sistare , Daniel Jordan , linux@armlinux.org.uk, schwidefsky@de.ibm.com, Heiko Carstens , john.stultz@linaro.org, sboyd@codeaurora.org, x86@kernel.org, LKML , mingo@redhat.com, hpa@zytor.com, douly.fnst@cn.fujitsu.com, peterz@infradead.org, prarit@redhat.com, feng.tang@intel.com, Petr Mladek , gnomes@lxorguk.ukuu.org.uk Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8929 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=507 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806190197 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > tsc_disabled is set when notsc is passed as kernel parameter. The reason we > > have notsc is to avoid timing problems on multi-socket systems. We already > > have a mechanism, however, to detect and resolve these issues by invoking > > tsc unstable path. Thus, make notsc to behave the same as tsc=unstable. > > notsc also excludes TSC from being used at all, while with your change its > suddenly used in sched_clock(). Hi Thomas, Thank you for the review. I will reword the patch comment. Currently, at the end it says: "Thus, make notsc to behave the same as tsc=unstable." To emphasize this, I will change the patch title to this: x86/tsc: redefine notsc to behave as tsc=unstable And in the comment I will mention that as a consequence of this change tsc is going to be used by sched_clock() when notsc is provided. Thank you, Pavel