linux-kernel - Re: [GIT PULL] cputime: Convert core use of cputime

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170130152928.GD2669@redhat.com>
Date:   Mon, 30 Jan 2017 16:29:29 +0100
From:   Stanislaw Gruszka <sgruszka@...hat.com>
To:     Frederic Weisbecker <fweisbec@...il.com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Tony Luck <tony.luck@...el.com>,
        Wanpeng Li <wanpeng.li@...mail.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paul Mackerras <paulus@...ba.org>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Rik van Riel <riel@...hat.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

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