linux-kernel - Re: CPU LED trigger: add hooks to generic code so that it works on x86

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: <20150527121723.GA3644@twins.programming.kicks-ass.net>
Date:	Wed, 27 May 2015 14:17:23 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Pavel Machek <pavel@....cz>
Cc:	mingo@...hat.com, linux-kernel@...r.kernel.org, cooloney@...il.com,
	rpurdie@...ys.net, j.anaszewski@...sung.com,
	linux-leds@...r.kernel.org
Subject: Re: CPU LED trigger: add hooks to generic code so that it works on
 x86

On Wed, May 27, 2015 at 10:47:18AM +0200, Pavel Machek wrote:
> 
> Distros should not enable this, IMO. But I don't think overhead is
> that big in either case.

Coming back from idle there might not be any cache, and you're adding at
least 1 more cache miss for loading cpu_trig -- those hurt. Looking at
that code, in case of !trig, you do a pointless function call before
bailing.

The thing is, there already is too much code in the wake from idle path,
adding more is not my favourite thing.

One thing you could do is wrap the call to ledtrig_cpu() in a
static_key, that way all we do is add some i$ pollution, but at least we
avoid the data cache miss when there's nothing to do.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/