>>> 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-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
