The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Jason Baron <jasonbaron0@gmail.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Vince Weaver <vince@deater.net>,
	"hillf.zj" <hillf.zj@alibaba-inc.com>,
	Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: Kernel broken on processors without performance counters
Date: Tue, 21 Jul 2015 17:43:27 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1507211726040.18576@nanos> (raw)
In-Reply-To: <20150721082107.GE18673@twins.programming.kicks-ass.net>

On Tue, 21 Jul 2015, Peter Zijlstra wrote:

> On Fri, Jul 10, 2015 at 04:13:59PM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 08, 2015 at 05:36:43PM -0700, Andy Lutomirski wrote:
> > > >> In what universe is "static_key_false" a reasonable name for a
> > > >> function that returns true if a static key is true?

It might be very well our universe, you just need access to the proper
drugs to feel comfortable with it.

> > > I think the current naming is almost maximally bad.  The naming would
> > > be less critical if it were typesafe, though.
> > 
> > How about something like so on top? It will allow us to slowly migrate
> > existing and new users over to the hopefully saner interface?

> > -#endif	/* _LINUX_JUMP_LABEL_H */
> > +static inline void static_key_enable(struct static_key *key)
> > +{
> > +	int count = static_key_count(key);
> > +
> > +	WARN_ON_ONCE(count < 0 || count > 1);
> > +
> > +	if (!count)
> > +		static_key_slow_inc(key);
> > +}
> > +
> > +static inline void static_key_disable(struct static_key *key)
> > +{
> > +	int count = static_key_count(key);
> > +
> > +	WARN_ON_ONCE(count < 0 || count > 1);
> > +
> > +	if (count)
> > +		static_key_slow_dec(key);
> > +}

The functions above are not part of the interface which should be used
in code, right?

To avoid further confusion, can we please move all the existing mess
and the new helpers into jump_label_internals.h and just put the new
interfaces in jump_label.h?

> > +/* -------------------------------------------------------------------------- */
> > +
> > +/*
> > + * likely -- default enabled, puts the branch body in-line
> > + */
> > +
> > +struct static_likely_key {
> > +	struct static_key key;
> > +};
> > +
> > +#define STATIC_LIKELY_KEY_INIT	(struct static_likely_key){ .key = STATIC_KEY_INIT_TRUE, }
> > +
> > +static inline bool static_likely_branch(struct static_likely_key *key)
> > +{
> > +	return static_key_true(&key->key);
> > +}
> > +
> > +/*
> > + * unlikely -- default disabled, puts the branch body out-of-line
> > + */
> > +
> > +struct static_unlikely_key {
> > +	struct static_key key;
> > +};
> > +
> > +#define STATIC_UNLIKELY_KEY_INIT (struct static_unlikely_key){ .key = STATIC_KEY_INIT_FALSE, }
> > +
> > +static inline bool static_unlikely_branch(struct static_unlikely_key *key)
> > +{
> > +	return static_key_false(&key->key);
> > +}
> > +
> > +/*
> > + * Advanced usage; refcount, branch is enabled when: count != 0
> > + */
> > +
> > +#define static_branch_inc(_k)	static_key_slow_inc(&(_k)->key)
> > +#define static_branch_dec(_k)	static_key_slow_dec(&(_k)->key)

Inlines please

> > +/*
> > + * Normal usage; boolean enable/disable.
> > + */
> > +
> > +#define static_branch_enable(_k)	static_key_enable(&(_k)->key)
> > +#define static_branch_disable(_k)	static_key_disable(&(_k)->key)

Ditto

All in all much more understandable than the existing horror.

Thanks,

	tglx

  reply	other threads:[~2015-07-21 15:44 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-08 15:17 Kernel broken on processors without performance counters Mikulas Patocka
2015-07-08 16:07 ` Peter Zijlstra
2015-07-08 16:54   ` Mikulas Patocka
2015-07-09 17:23     ` [PATCH] x86: Fix static_key in load_mm_cr4() Peter Zijlstra
2015-07-09 19:11       ` Mikulas Patocka
2015-07-10  8:27       ` [tip:perf/urgent] x86, perf: Fix static_key bug " tip-bot for Peter Zijlstra
2015-07-08 17:37   ` Kernel broken on processors without performance counters Andy Lutomirski
2015-07-08 20:04     ` Jason Baron
2015-07-09  0:36       ` Andy Lutomirski
2015-07-10 14:13         ` Peter Zijlstra
2015-07-10 15:29           ` Jason Baron
2015-07-21  8:21           ` Peter Zijlstra
2015-07-21 15:43             ` Thomas Gleixner [this message]
2015-07-21 15:49               ` Peter Zijlstra
2015-07-21 15:51                 ` Andy Lutomirski
2015-07-21 16:12                   ` Peter Zijlstra
2015-07-21 16:57                     ` Jason Baron
2015-07-23 14:54                       ` Steven Rostedt
2015-07-21 18:15                     ` Borislav Petkov
2015-07-21 18:50                       ` Jason Baron
2015-07-21 18:54                         ` Andy Lutomirski
2015-07-21 19:00                           ` Valdis.Kletnieks
2015-07-21 19:29                             ` Andy Lutomirski
2015-07-21 23:49                               ` Valdis.Kletnieks
2015-07-22  4:24                         ` Borislav Petkov
2015-07-22 17:06                           ` Jason Baron
2015-07-23 10:42                             ` Peter Zijlstra
2015-07-23 10:53                               ` Borislav Petkov
2015-07-23 14:19                               ` Jason Baron
2015-07-23 14:33                                 ` Peter Zijlstra
2015-07-23 14:49                                   ` Peter Zijlstra
2015-07-23 19:14                                     ` Jason Baron
2015-07-24 10:56                                       ` Peter Zijlstra
2015-07-24 12:36                                         ` Peter Zijlstra
2015-07-24 14:15                                           ` Jason Baron
2015-07-23 14:58                                 ` Peter Zijlstra
2015-07-23 15:34                               ` Steven Rostedt
2015-07-23 17:08                                 ` Peter Zijlstra
2015-07-23 17:18                                   ` Steven Rostedt
2015-07-23 17:33                                   ` Jason Baron
2015-07-23 18:12                                     ` Steven Rostedt
2015-07-23 19:02                                     ` Peter Zijlstra
2015-07-23 17:35                                   ` Andy Lutomirski
2015-07-23 17:54                                   ` Borislav Petkov
2015-07-23 19:02                                     ` Peter Zijlstra
2015-07-24  5:29                                       ` Borislav Petkov
2015-07-24 10:36                                         ` Peter Zijlstra
2015-07-22 20:43                           ` Mikulas Patocka
2015-07-21 15:53                 ` Thomas Gleixner
2015-07-21 15:54                 ` Peter Zijlstra
2015-07-09 17:11       ` Peter Zijlstra
2015-07-09 19:15         ` Jason Baron
2015-07-14  9:35 ` Borislav Petkov
2015-07-14 12:43   ` Mikulas Patocka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1507211726040.18576@nanos \
    --to=tglx@linutronix.de \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=aarcange@redhat.com \
    --cc=acme@kernel.org \
    --cc=bp@alien8.de \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=jasonbaron0@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mpatocka@redhat.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vince@deater.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox