Date:   Wed, 1 Feb 2023 23:10:43 +0800
From:   Feng Tang <feng.tang@intel.com>
To:     Thomas Gleixner <tglx@linutronix.de>
CC:     "Paul E. McKenney" <paulmck@kernel.org>,
        <linux-kernel@vger.kernel.org>, <john.stultz@linaro.org>,
        <sboyd@kernel.org>, <corbet@lwn.net>, <Mark.Rutland@arm.com>,
        <maz@kernel.org>, <kernel-team@meta.com>, <neeraju@codeaurora.org>,
        <ak@linux.intel.com>, <zhengjun.xing@intel.com>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "Daniel Lezcano" <daniel.lezcano@linaro.org>,
        Waiman Long <longman@redhat.com>, <x86@kernel.org>
Subject: Re: [PATCH v2 clocksource 6/7] clocksource: Verify HPET and PMTMR
 when TSC unverified
Message-ID: <Y9qA81mcxeaHYxJX@feng-clx>
References: <20230125002708.GA1471122@paulmck-ThinkPad-P17-Gen-1>
 <20230125002730.1471349-6-paulmck@kernel.org>
 <87wn51znsh.ffs@tglx>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87wn51znsh.ffs@tglx>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?g3Reco604SAaXfJfLgR5XrJiLKgbZt9le7d4BKBCGCp3XQVEjlY+hJLK5eEs?=
 =?us-ascii?Q?r5/KMdYun+C2ztBokKlKvZn4EZ0PgbLmxoyEBgeazfdYYVpwQDU5cIAMcF/h?=
 =?us-ascii?Q?P1w2/GYY1aOtaMsQFovbDEtWkH/zevh9ih1Kz2i2fElyvcbRg7JUYfn7z1Ie?=
 =?us-ascii?Q?qRbFSKgnPKWtFdyExXI+sXnYLdaNcvBmpsJiIPGvDkbSRK0A78D4hg0Nldp3?=
 =?us-ascii?Q?OMa8gi1WIDn/gj7EvRWA6JoAGf9ugUP8x1c2fKoihYh3LLxfLRCBgIj9AQOx?=
 =?us-ascii?Q?xmSW2plP0+bRem/Z0F60SdidVCQG3y9ON5jSt+6o47+Ogw8CY5/hoSAWpg9u?=
 =?us-ascii?Q?g+iONVyWcfL4P2Kc2QztKZW6jTnG73c2l5DmjurltXGRr2EI+XYkt3FszvSe?=
 =?us-ascii?Q?y+cs/HnX4bZPdIXBbItRFyXRoKh5JgayOEEecg/Bnuids+PNx9hkPzxPTm1A?=
 =?us-ascii?Q?uXbupMppSD+sHBH7ErFbfG/7Lf00z7/wlriXclZgEWbiVmfbZPLrTlph501d?=
 =?us-ascii?Q?hO2yTIN+Vmu2LdPoTGUYDN6YOHwDsov6Yq+9edyLdy/xSXEMo+WyUZAgTJLM?=
 =?us-ascii?Q?mytZzUXm+o/6BODqLXjLjlAxKA+h+OCJWJOCRp3Ilmul2GLifD6R/4i/WwAT?=
 =?us-ascii?Q?nG0H0Amu3bAC1kmSwV4ZVPKzePjuJ9KbB/uvM5YxtC6mQYT3+L3rzZc226v1?=
 =?us-ascii?Q?Fy1jXZq/3h7xGArbKKGyM75PuD3klSAVQE1FVPdx6VEsgsCxYAfEteXhb5qC?=
 =?us-ascii?Q?SJaImvHJPydR1kCZpR3vIRi6cvlc+jsWDgbpa/zompUXy+3ftYyYn9pO7OT5?=
 =?us-ascii?Q?evIhf11egF1QyOMqiWx331ytAOSwwzkwYfv0ny6IlOdmxaezHq4V/kHoxquj?=
 =?us-ascii?Q?AOnKFJ/3R+N1+fPjuKrosBtaroOLRU5LzHd3bhUlwiTPy0TK6hq9+9q6R2VY?=
 =?us-ascii?Q?3E3rsjAPBn+MQWFmyjOnz/T4LRJYyr8t6PqUOUsNQESUL68BJtsGQvJPx//I?=
 =?us-ascii?Q?6I2qAun0TIceoYAI4a7KtjT5dfdjO/RwvbTCGJuTfZQiyBd3V2Rpv2zdNAvC?=
 =?us-ascii?Q?gbEMbN1jFfyIkfu8YJdRF//LKKTLk+L7S56zV5LoS9A+T7zj8rvPW26yKddj?=
 =?us-ascii?Q?ZYifEV5XgKpTh9j7W6qwljdSEhT0qXdH3lAvk6Mb6RUJVRK76a5Dm/HlksF4?=
 =?us-ascii?Q?9QHoOXrZVW14hx2RA1mECErauktLLHL3LtpVj2ZrE/2T/VT7PcC4X+VIa/0I?=
 =?us-ascii?Q?bZrwVEUYiX65ZrpiOlYEdHfEMUqiwYTM6GsIjt0tldxc1bo1COAr97M2PJkl?=
 =?us-ascii?Q?TJo+nRZpMM7vkqyBa5WZbEGt5PFU5Rx1acRM6KPVZO+XlmmtC+xxR+m5TFOY?=
 =?us-ascii?Q?QxdQ7zYfEax2BYDVJLT27mlZ5sXJkislTOFwUWjF7tzr139cXKlpIIETizDH?=
 =?us-ascii?Q?b9PYAsDJC2zbVa4dFCppTk64d5AYsISO/bv3InbnIEhlPAKDU0wGzIQWb/qy?=
 =?us-ascii?Q?eYpKu1Ry4arg6JZpyttZZkPdgS3xh0udjrJXYnV5bK0lY97t64089kq3qPtf?=
 =?us-ascii?Q?C8SK0aHKrXwP99iu+zL2TiR3LJF1i7PelF0qGSH7?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e99629f-5789-4861-a061-08db0467281c
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6304.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2023 15:15:30.6663
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: SiA9svP/fTS7vYzSoRJvXOOca4vBL77GRgrV52eTmnIbS9lbEkoC2lVKWPnQ7WhcHwTrtXc2so1zUTII3W3N1A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR11MB6493
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Thomas,

On Wed, Feb 01, 2023 at 11:24:14AM +0100, Thomas Gleixner wrote:
> Paul!
> 
> On Tue, Jan 24 2023 at 16:27, Paul E. McKenney wrote:
> > On systems with two or fewer sockets, when the boot CPU has CONSTANT_TSC,
> > NONSTOP_TSC, and TSC_ADJUST, clocksource watchdog verification of the
> > TSC is disabled.  This works well much of the time, but there is the
> > occasional production-level system that meets all of these criteria, but
> > which still has a TSC that skews significantly from atomic-clock time.
> > This is usually attributed to a firmware or hardware fault.  Yes, the
> > various NTP daemons do express their opinions of userspace-to-atomic-clock
> > time skew, but they put them in various places, depending on the daemon
> > and distro in question.  It would therefore be good for the kernel to
> > have some clue that there is a problem.
> >
> > The old behavior of marking the TSC unstable is a non-starter because a
> > great many workloads simply cannot tolerate the overheads and latencies
> > of the various non-TSC clocksources.  In addition, NTP-corrected systems
> > sometimes can tolerate significant kernel-space time skew as long as
> > the userspace time sources are within epsilon of atomic-clock time.
> >
> > Therefore, when watchdog verification of TSC is disabled, enable it for
> > HPET and PMTMR (AKA ACPI PM timer).  This provides the needed in-kernel
> > time-skew diagnostic without degrading the system's performance.
> 
> I'm more than unhappy about this. We finally have a point where the TSC
> watchdog overhead can go away without adding TSC=reliable to the kernel
> commandline.
> 
> Now you add an unconditionally enforce the watchdog again in a way which
> even cannot be disabled on the kernel command line.

Yes, this is a valid concern. Waiman, Paul and I discussed this and
had some proposal to handle this side effect, like only watchdoging 
HPET/ACPI-PM timer for a short period of time in this case.
https://lore.kernel.org/lkml/20221227183819.GI4001@paulmck-ThinkPad-P17-Gen-1/
My bad that I didn't follow up as my proposed code looked ugly as
bringing more complexsities. Does the idea of setting a watchdog
time limit sound fine to you?  

Thanks,
Feng

> Patently bad idea, no cookies for you!
> 
> Thanks,
> 
>         tglx