Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1222662 > unrolled thread

static key arrays?

Back to article view | Back to linux.kernel

Contents

  static key arrays? Johannes Berg <johannes@sipsolutions.net> - 2015-09-11 11:50 +0200
    Re: static key arrays? Peter Zijlstra <peterz@infradead.org> - 2015-09-11 13:20 +0200
      Re: static key arrays? Johannes Berg <johannes@sipsolutions.net> - 2015-09-11 14:20 +0200
        Re: static key arrays? Rasmus Villemoes <linux@rasmusvillemoes.dk> - 2015-09-11 16:50 +0200
          Re: static key arrays? Johannes Berg <johannes@sipsolutions.net> - 2015-09-11 17:00 +0200
    Re: static key arrays? "Baron, Jason" <jbaron@akamai.com> - 2015-09-11 13:30 +0200

#1222662 — static key arrays?

Hi Peter, Jason, all,

Per the recent type-safe API changes, it's no longer easy to generate
an array of static keys. I was planning to do that for a set of very
unlikely debug options.

It sounds like you're planning to remove the previous API entirely at
some point, so I'm wondering if you've given any thought to this
possibility.

I briefly played with the idea of adding a macro for that, but the
necessary "REPEAT(n, d)" macro for the initialisation becomes ugly
pretty quickly and, afaict, needs to have enough macros for the maximum
expected numbers.

For the case I was looking at it's static_key_false so a zero
-initialized array would be sufficient, but that can't be done easily
with a static_key_true.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1222720

On Fri, Sep 11, 2015 at 11:45:35AM +0200, Johannes Berg wrote:
> Hi Peter, Jason, all,
> 
> Per the recent type-safe API changes, it's no longer easy to generate
> an array of static keys. I was planning to do that for a set of very
> unlikely debug options.
> 
> It sounds like you're planning to remove the previous API entirely at
> some point, so I'm wondering if you've given any thought to this
> possibility.

If possible I'd kill static_key_{true,false}() and
static_key_slow_{inc,dec}. Not sure how much more makes sense, the new
interface builds on parts of the old stuff.

> I briefly played with the idea of adding a macro for that, but the
> necessary "REPEAT(n, d)" macro for the initialisation becomes ugly
> pretty quickly and, afaict, needs to have enough macros for the maximum
> expected numbers.
> 
> For the case I was looking at it's static_key_false so a zero
> -initialized array would be sufficient, but that can't be done easily
> with a static_key_true.

As long as its all the same type it shouldn't be too hard;

struct static_key_false array[n] = { STATIC_KEY_FALSE_INIT, };

or something like that.

The scheduler has an array of these things that has different types;
which if going to be even more interesting. I'm not quite sure what to
do there, but I think it'll end up relying on the fact that both types
share the same base (struct static_key) and involve a lot of type
casting :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222767

On Fri, 2015-09-11 at 13:10 +0200, Peter Zijlstra wrote:
> 
> struct static_key_false array[n] = { STATIC_KEY_FALSE_INIT, };
> 
> or something like that.

Yeah, ok, this would be sufficient for me - no need to mix different
types. I don't think that initializer works, but I guess we can just
duplicate it in the code - unless we can rely on zero-initialization
being sufficient.

My mistake was assuming that the only API was the macros, but of if we
just use the new struct names (struct static_key_false) without the
macros then there isn't really an issue.

Thanks,
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222889

On Fri, Sep 11 2015, Johannes Berg <johannes@sipsolutions.net> wrote:

> On Fri, 2015-09-11 at 13:10 +0200, Peter Zijlstra wrote:
>> 
>> struct static_key_false array[n] = { STATIC_KEY_FALSE_INIT, };
>> 
>> or something like that.
>
> Yeah, ok, this would be sufficient for me - no need to mix different
> types. I don't think that initializer works, but I guess we can just
> duplicate it in the code 

That's inconvenient for large arrays. I think the 'or something' would
be the range initialization supported by gcc (and I think also clang):

struct static_key_false array[N] = { [0 ... N-1] = STATIC_KEY_FALSE_INIT };

Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222898

On Fri, 2015-09-11 at 16:41 +0200, Rasmus Villemoes wrote:
> 
> That's inconvenient for large arrays. I think the 'or something' would
> be the range initialization supported by gcc (and I think also clang):
> 
> struct static_key_false array[N] = { [0 ... N-1] = STATIC_KEY_FALSE_INIT };
> 

Ah, I wasn't aware of that extension. That's indeed much more
convenient than the CPP trick I was thinking of :)

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222724

Hi,

Perhaps a bit wasteful, but I think you could have 2 arrays- an all true one and an all false one. And then just pick the right one at compile time? This also needs to be addressed for sched_feat() as well...

Thanks,

-Jason



> On Sep 11, 2015, at 5:46 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> Hi Peter, Jason, all,
> 
> Per the recent type-safe API changes, it's no longer easy to generate
> an array of static keys. I was planning to do that for a set of very
> unlikely debug options.
> 
> It sounds like you're planning to remove the previous API entirely at
> some point, so I'm wondering if you've given any thought to this
> possibility.
> 
> I briefly played with the idea of adding a macro for that, but the
> necessary "REPEAT(n, d)" macro for the initialisation becomes ugly
> pretty quickly and, afaict, needs to have enough macros for the maximum
> expected numbers.
> 
> For the case I was looking at it's static_key_false so a zero
> -initialized array would be sufficient, but that can't be done easily
> with a static_key_true.
> 
> johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web