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

[Jan Beulich]

>>> On 06.01.12 at 12:03, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Fri, 06 Jan 2012 07:40:29 +0000 "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> 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.
> 
> What are these alignment holes?  I'd assumed (without thinking a lot)
> that they were little three or two byte gaps because sizeof(bool)=1 or
> 2.

The holes are typically sizeof(long) - 1 bytes (i.e. 7 on 64-bit), with
some cases of smaller/larger ones.

> But I see that sizeof(bool) is actually 4, so I don't know what
> you're talking about.

They're 1-byte variables, and System.map confirms this (with the
patch in place):

ffffffff81638808 d __warned.24033
ffffffff81638809 d __warned.25205
ffffffff8163880a d __warned.30138
ffffffff8163880b d __warned.27363
...

> Apparently there is some gcc behaviour which you know about and I
> don't.

No magic gcc behavior is involved here afaict - this example

typedef _Bool bool;

bool b;

bool test(void) {
	return b;
}

unsigned size(void) {
	return sizeof(bool);
}

unsigned align(void) {
	return __alignof__(bool);
}

confirms that with whatever gcc I try, sizeof and __alignof__
produce 1 on x86.

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/