Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5102030ybl; Tue, 14 Jan 2020 03:33:42 -0800 (PST) X-Google-Smtp-Source: APXvYqw2BsC3wwrmkfNPsmk0MO86pQ8nN++rR9lz8vJ+WIVGGr28K8dcIIQYo7gg/ImJxx6Nhw4y X-Received: by 2002:a9d:12cf:: with SMTP id g73mr1988477otg.329.1579001622276; Tue, 14 Jan 2020 03:33:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579001622; cv=none; d=google.com; s=arc-20160816; b=UZPw7ad6pOpTf+n3KACVVLuKHXL8gKscz0VBIy+jQghgJ/mwKkdYUwjAzBX5FUMXJC 4ybfyclS6GImKuGaiA0lha7LcP2K8Zm+okb9CShFQMEhfN8IOdkliP54R1WUmO36pZ2M dr21btrca3JtNP3zFxmuzcMjau2SM5MZHoxxu79XZpQVhnoM5nMexxMUDjXbNdMXvps7 4RCVvaUld2OkIqSFr8qj8XFnKCrj3x8StZ4AjDlhTZM/BD+XxLaAQ/J+GMX43Fd5Nlg1 zg5uFjjcVHdGJFN9YU+NMtT08KjtodvtZ1L+deeMlLVgflI0/dohSlcaMcYBfO3OUXkK b87w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=hY8crQPK0SRW5WXKpzF9xEMaMNECKojVicoiwxBFPNw=; b=bmyU4PpH8bCFGxOhrPZeEeGeBrA7kgR+7kecO1cMZZZgzt7ASjztXJs9m2ySZukEOM DNYcpICvN4HChL7mzEe298E8bJd1W41TwY81tdI353ezMhlwHxLNlp5u1z5d0FkNkD+A nzByXcNqgtGK49izx4RxYh9tUJUWE9mMUPoqYveIB9benytTr5HlEyIU1rOcMNB4wBOB 9badkEBD0Ab2GLqXy+/Lb3qyn+TA9t5870AzIwooCWtdK/u6t1QKXxpgh1zv85F6bGMs E3IivrhIBGCkNLIatmXe9syei8YjSgt3Es388eyY1sePti36CmxjK7t+ItUtex0UyiBZ BjMA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v23si8198309otk.321.2020.01.14.03.33.28; Tue, 14 Jan 2020 03:33:42 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729314AbgANLcP (ORCPT + 99 others); Tue, 14 Jan 2020 06:32:15 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:42790 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725956AbgANLcO (ORCPT ); Tue, 14 Jan 2020 06:32:14 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1irKQQ-0002Kq-3S; Tue, 14 Jan 2020 12:31:58 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 8410B101DEE; Tue, 14 Jan 2020 12:31:57 +0100 (CET) From: Thomas Gleixner To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , arnd@arndb.de, vincenzo.frascino@arm.com, luto@kernel.org Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, x86@kernel.org Subject: Re: [RFC PATCH v3 06/12] lib: vdso: __iter_div_u64_rem() is suboptimal for 32 bit time In-Reply-To: <5b38617a2ca4f719760aafbdb6115eaad28c0640.1578934751.git.christophe.leroy@c-s.fr> References: <5b38617a2ca4f719760aafbdb6115eaad28c0640.1578934751.git.christophe.leroy@c-s.fr> Date: Tue, 14 Jan 2020 12:31:57 +0100 Message-ID: <875zheclzm.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: > Using __iter_div_ulong_rem() is suboptimal on 32 bits. > Nanoseconds are only 32 bits, and VDSO data is updated every 10ms > so nsec will never overflow 32 bits. That's theory and perhaps true for bare metal, but there is no guarantee on VIRT that the CPU which has the timekeeping duty assigned is not scheduled out for longer than 4 seconds. Thanks, tglx