linux-kernel - Re: [PATCH 7/7] x86,idle: do not leave mm in idle state

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: <CALCETrX9PZEHs9bj476bj5qEb1aXtiH0K8G998t1+CbUuiaGmg@mail.gmail.com>
Date:   Fri, 22 Jun 2018 15:05:24 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Rik van Riel <riel@...riel.com>
Cc:     Andrew Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Mike Galbraith <efault@....de>, songliubraving@...com,
        kernel-team <kernel-team@...com>
Subject: Re: [PATCH 7/7] x86,idle: do not leave mm in idle state

On Fri, Jun 22, 2018 at 1:19 PM Rik van Riel <riel@...riel.com> wrote:
>
> On Fri, 2018-06-22 at 09:01 -0700, Andy Lutomirski wrote:
> > Hmm, fair enough.  I think a better heuristic would be if the
> > estimated idle duration is more than, say, 10ms.  I *think* the code
> > has been cleaned up enough that this is easy now.  (Using time
> > instead
> > of C6 will make it a lot less dependent on which idle driver is in
> > use.)
>
> This particular bit of code is only in intel_idle
> though, and not every cpuidle governor estimates
> an idle duration, nor does it get passed up the
> stack (presumably because it not always exists).
>
> I will just drop this patch for now, and see if
> adding back in the patch that skips manipulation
> of the mm_cpumask(&init_mm), since that might make
> leave_mm() a little cheaper.
>
> We would still have excess manipulation of the
> bitmask when re-entering the task from what should
> have been lazy TLB mode, but total cache line
> contention would likely still be down from where
> it is before that patch.
>

Agreed.

I think the right solution if you want that last little bit of
performance is to get rid of the code in intel_idle and to add it in
the core idle code.  We have fancy scheduler code to estimate the idle
time, and we should use it here IMO.