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] [day] [month] [year] [list]

Date:   Fri, 22 Jun 2018 20:55:44 -0400
From:   Rik van Riel <riel@...riel.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     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, 2018-06-22 at 15:05 -0700, Andy Lutomirski wrote:

> 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.

Good point.

However, I suspect we have some lower hanging
larger fruit to tackle first.

Every time we go into lazy TLB mode, we take
a refcount on the mm. Every time we leave lazy
TLB mode, we drop the refcount.

Every time we switch from the idle task to a
kernel thread, the kernel thread takes a
refcount, and the idle task drops it. Every
time we switch back, we do the same dance in
reverse.

I am working on a patch to grab the refcount
once, and hang onto it while a particular mm
is that CPU's lazy_mm.

We can release it when we switch to a task
with a different mm.

The patches we have so far get rid of a lot of
the pounding on mm_cpumask(mm).

That patch should help us also get rid of tasks
pounding on mm->count.

After that, the idle state thing is probably
of pretty small impact, though I suspect it will
still be worth tackling :)

As an aside, isn't the fancy CPU power management
stuff in the scheduler cpufreq, not cpuidle? The
cpuidle stuff in kernel/sched/idle.c looks like it
will just call down into the menu governor (and
maybe the ladder governor on some systems??)

-- 
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)