From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932380AbcLIEwX (ORCPT ); Thu, 8 Dec 2016 23:52:23 -0500 Received: from mail-oi0-f50.google.com ([209.85.218.50]:33385 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751570AbcLIEwW (ORCPT ); Thu, 8 Dec 2016 23:52:22 -0500 MIME-Version: 1.0 In-Reply-To: <20161208202623.883855034@linutronix.de> References: <20161208202623.883855034@linutronix.de> From: John Stultz Date: Thu, 8 Dec 2016 20:52:20 -0800 Message-ID: Subject: Re: [patch 0/6] timekeeping: Cure the signed/unsigned wreckage To: Thomas Gleixner Cc: LKML , Peter Zijlstra , Ingo Molnar , David Gibson , Liav Rehana , Chris Metcalf , Richard Cochran , Parit Bhargava , Laurent Vivier , "Christopher S. Hall" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 8, 2016 at 12:49 PM, Thomas Gleixner wrote: > This series addresses the recently reintroduced signed vs. unsigned > wreckage by cleaning up the whole call chain instead of just making a > simple s64 -> u64 'fix' at one point and keeping the rest signed, which > eventually led to the unintended signed conversion and brought back an > issue that was fixed a year ago already. > > Here is the queue: > > timekeeping: Force unsigned clocksource to nanoseconds conversions > timekeeping: Make the conversion call chain consistently unsigned > timekeeping: Get rid of pointless typecasts > > These three patches are definitely urgent material > > timekeeping: Use mul_u64_u32_shr() instead of open coding it Thanks for putting these together Thomas! So I'm happy with the set above. > Can wait for 4.11, but for sanity reasons it should go into 4.10 > > [RFD] timekeeping: Provide optional 128bit math > > This is material for discussion. I'm not sure if we want to do that at > all, but it addresses the insanities of long time scheduled out VMs. Yea. Here I feel like there has to be some bound after which we don't function when we're starved of interrupts. On some systems it will be the hardware clocksource wrapping, on other systems its the multiplication overflowing. I think we should avoid the system failing critically (which the initial patches address), as there are cases like halting the system via kdb or freezing a VM for a long period of time (hosts suspending is an example), but having a smallish time inconsistency event in this case doesn't seem tragic to me. Providing a config option for folks who want robust time correctness in the event of insane system scheduling/interrupt latency isn't something I object to, but I worry it will just push the boundary of what is "expected broken by design" out further (why bother suspending/resuming the timekeeping subsystem when you can just starve it, etc). thanks -john