lkml.org 
[lkml]   [2012]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] consolidate WARN_...ONCE() static variables
>>> On 06.01.12 at 12:03, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 06 Jan 2012 07:40:29 +0000 "Jan Beulich" <JBeulich@suse.com> wrote:
>
>> >>> On 05.01.12 at 22:03, Andrew Morton <akpm@linux-foundation.org> wrote:
>> > On Thu, 05 Jan 2012 11:09:40 +0000
>> > "Jan Beulich" <JBeulich@suse.com> wrote:
>> >
>> >> >>> On 05.01.12 at 00:03, Andrew Morton <akpm@linux-foundation.org> wrote:
>> >> > On Thu, 22 Dec 2011 15:53:49 +0000
>> >> > "Jan Beulich" <JBeulich@suse.com> 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



\
 
 \ /
  Last update: 2012-01-06 13:41    [W:0.682 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site