linux-kernel - Re: [PATCH] leds/trigger/activity: add a system activity LED trigger

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: <20170215104212.GC19195@1wt.eu>
Date:   Wed, 15 Feb 2017 11:42:12 +0100
From:   Willy Tarreau <w@....eu>
To:     Pavel Machek <pavel@....cz>
Cc:     Richard Purdie <rpurdie@...ys.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org
Subject: Re: [PATCH] leds/trigger/activity: add a system activity LED trigger

Hi Pavel!

On Wed, Feb 15, 2017 at 11:24:26AM +0100, Pavel Machek wrote:
> On Sun 2017-02-12 00:41:54, Willy Tarreau wrote:
> > The "activity" trigger was inspired by the heartbeat one, but aims at
> > providing instant indication of the immediate CPU usage. Under idle
> > condition, it flashes 10ms every second. At 100% usage, it flashes
> > 90ms every 100ms. The blinking frequency increases from 1 to 10 Hz
> > until either the load is high enough to saturate one CPU core or 50%
> > load is reached on a single-core system. Then past this point only the
> > duty cycle increases from 10 to 90%.
> > 
> > This results in a very visible activity reporting allowing one to
> > immediately tell whether a machine is under load or not, making it
> > quite suitable to be used in clusters.
> > 
> > Signed-off-by: Willy Tarreau <w@....eu>
> 
> Hmm. Evil question. Why not use LEDS_TRIGGER_CPU instead?
> 
> Recently it gained support for "summarizing" all the cpus onto one
> led.

That's not an evil question, it's perfectly correct as it's the first
one I've tried :-) But it's basically an all on or all off report, you
see if the CPU is instantly being used or not. Also, when the CPU is
idle you have no way to tell the machine is not dead, and when it's
saturated you have no way to check it's not stuck. In the end I found
the lack of progressivity in the visual report to be very problematic
for my typical use case where I want to be able to spot in one second
if a machine in my build farm is under-loaded.

I thought about modifying the cpu trigger to support a different mode
of reporting but I noticed that the two approaches are quite different
and very likely suit different purposes, even if there can be some
overlap for a number of use cases. I think that most users just want
to see if something is running or draining their battery and CPU is
better suited there. But to differenciate between 10, 50 and 100%
usage, it really is not (at least for me).

Cheers,
Willy