From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932317AbdA3P60 (ORCPT ); Mon, 30 Jan 2017 10:58:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42284 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750887AbdA3P6T (ORCPT ); Mon, 30 Jan 2017 10:58:19 -0500 Date: Mon, 30 Jan 2017 16:29:29 +0100 From: Stanislaw Gruszka To: Frederic Weisbecker Cc: Ingo Molnar , LKML , Tony Luck , Wanpeng Li , Peter Zijlstra , Michael Ellerman , Heiko Carstens , Benjamin Herrenschmidt , Thomas Gleixner , Paul Mackerras , Fenghua Yu , Rik van Riel , Martin Schwidefsky Subject: Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs Message-ID: <20170130152928.GD2669@redhat.com> References: <1485751603-15913-1-git-send-email-fweisbec@gmail.com> <20170130143223.GC2669@redhat.com> <20170130145648.GA16945@lerouge> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170130145648.GA16945@lerouge> User-Agent: Mutt/1.5.20 (2009-12-10) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 30 Jan 2017 15:31:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 30, 2017 at 03:56:49PM +0100, Frederic Weisbecker wrote: > On Mon, Jan 30, 2017 at 03:32:24PM +0100, Stanislaw Gruszka wrote: > > On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > > > Now lets admit one drawback: s390 and powerpc with > > > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE have new cputime_t to nsecs conversion > > > on cputime accounting path. But this should be leveraged by the recent > > > changes which delay the cputime accounting to tick and context switch. > > > > I think it would be worth to mention that there are other drawbacks on > > 32bit architectures that use cputime-jiffies currently, like: > > - cache utilization will be worse > > Due to utime and stime becoming 64 bits? Yeah indeed. :-) Well, it is possible that something that use to fit into one cache line, now will be consuming 2 cache lines and results more cache misses. In general, this patchset seems to be nice cleanup of code, but how it affect runtime efficiency is not clear and might depend on .config and architecture. However seems 32bit embedded users will be affected negatively. Stanislaw