Re: [PATCH] consolidate WARN_...ONCE() static variables

[Jan Beulich]

>>> On 05.01.12 at 22:03, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 05 Jan 2012 11:09:40 +0000
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 05.01.12 at 00:03, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Thu, 22 Dec 2011 15:53:49 +0000
>> > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > 
>> >> Due to the alignment of following variables, these typically consume
>> >> more than just the single byte that 'bool' requires, and as there are
>> >> a few hundred instances, the cache pollution (not so much the waste of
>> >> memory) sums op. Put these variables into their own section, outside
>> >> of half way frequently used memory range.
>> >> 
>>
>> ...
>>
>> > printk_once() should also be converted.  And ata_print_version_once(),
>> > if it insists on continuing to exist.
>> 
>> I disagree for those (and intentionally didn't touch printk_once();
>> wasn't aware of the other) - at best this could get marked
>> __read_mostly, but that's not the subject of this patch.
> 
> Confused.  It is exactly the subject of the patch?

No - the goal here is to eliminate the wasteful alignment holes
created by the __warned variables in the WARN_...ONCE()
instances. These get accessed past and unlikely() condition,
and hence get moved into a separate data section (so they
would all end up together, with no holes in between).

The printk_once() situation is quite different: The variables get
accessed each time the code in question gets executed, and
hence cannot be considered on an unlikely code path without
additional knowledge of the surrounding code. Consequently
they don't belong into the same data section as the ones that
get moved here.

>> > Also rcu_lockdep_assert().
>> 
>> This one I mostly agree - the access is at least sitting past the
>> debug_lockdep_rcu_enabled() check, albeit not in an unlikely()
>> code path.
> 
> What does "unlikely" have to do with any of this?

See above.

> I'm suspecting that there is some changelog crappiness going on here. 
> What didn't you tell us?

I think the original description says all that it has to. It doesn't
care to say why others don't get converted, but I don't think
that's to be expected of it either (imagine how patch descriptions
would start looking like if everything that wasn't done in patch
was also described).

Jan

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