linux-kernel - Re: [PATCH 2/5] x86: remove idle

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]

Message-ID: <alpine.DEB.2.20.1612082340170.3609@nanos>
Date:   Thu, 8 Dec 2016 23:53:16 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Pavel Machek <pavel@....cz>
cc:     Len Brown <lenb@...nel.org>, x86@...nel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Len Brown <len.brown@...el.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 2/5] x86: remove idle_notifier

On Thu, 8 Dec 2016, Pavel Machek wrote:
> On Thu 2016-12-08 10:18:13, Thomas Gleixner wrote:
> > I'm dealing with low-speed systems for 20 years now and that LED was never
> > important for me, quite the contrary, it's annoying to have the extra work
> > in the idle wakeup path which causes extra pointless latency. If you can't
> > figure out your keypress lag without that LED then feel free to patch your
> > own kernel, but stop trying to impose that nonsense on everyone.
> 
> The kernel already has the hooks, and they did not seem to bother
> anyone.

The have bothered a lot of people up to the point where we could remove
them, simply because they are pointless ballast and overhead in the wake
from idle path.

> Arm already has the functionality, and it is useful. You may
> not care, but so what. Leds are broken on x86, plain and simple.

BlinkenLEDs for idle were never available on x86 to begin with, so they
can't be broken.

Aisde of that the vast majority of x86 systems simply do not have LEDs
which are accessible from that context. So just to support a very
questionable use case with a very limited usefulness you want to impose
extra code into a code path which is already known to be too heavy weight
and people working on it to reduce the overhead.

> Perhaps that should not be your decision?

Feel free to complain to Linus. My maintainer decision stands.

> Feel free to patch it out of your kernel. Or feel free to argue that it
> needs to be removed from arm. But having unneccessary differences between
> architectures is just ugly.

Following that argumentation would require to add this to the core idle
code, so _ALL_ architetures have access to this, but that got turned down
by the core maintainers a more than a year ago for the very same reason.

Thanks,

	tglx