RE: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths"

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Now I think even '16' can't cover all cases. It's possible for a user defined 
structure with .align directive to force by '32' or larger, and then allocator 
happens to have similar check upon SMP_CACHE_BYTES like case in this thread. 
Because both structure definition and allocator may have no idea about IA64 
trick of saving space for UP. Max alignment of any C style only solves the 
natural alignment case, but not above forced one. We can just give its real 
assumption to SMP_CACHE_BYTES - cache line size. ;-)

Thanks,
Kevin

>-----Original Message-----
>From: dmosberger@xxxxxxxxx [mailto:dmosberger@xxxxxxxxx] On Behalf Of David
>Mosberger-Tang
>Sent: 2005年11月23日 3:34
>To: Luck, Tony
>Cc: Tian, Kevin; Rusty Russell; Xen Mailing List; Tony Breeds; 
>djm@xxxxxxxxxxxxxxx;
>linux-ia64@xxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling 
>forfast
>paths"
>
>I don't think it's worth going to great lengths to preserve the
>SMP_CACHE_BYTES == 8 for UP.  We should be able to just make it 16 and
>be done with it (perhaps adding a comment that SMP_CACHE_BYTES must be
>>= max alignment of any C type).
>
>  --david
>
>On 11/22/05, Luck, Tony <tony.luck@xxxxxxxxx> wrote:
>> This comment:
>> >   /*
>> >    * The "aligned" directive can only _increase_ alignment, so this is
>> >    * safe and provides an easy way to avoid wasting space on a
>> >    * uni-processor:
>> >    */
>> suggests that we only expected SMP_CACHE_BYTES to be used in "aligned"
>> directives, where having a smaller value than the actual alignment
>> requirement of some object would simply be ignored by the compiler.
>>
>> A search for SMP_CACHE_BYTES across the kernel picks up a few drivers
>> that don't follow this usage model.   E.g. drivers/net/acenic.c might
>> print a warning about unsupported cache line size on a UP ia64.
>>
>> Your usage:
>>         BUG_ON(align > SMP_CACHE_BYTES);
>>
>> is another instance of this define being used in a way that ia64
>> didn't expect (it appears that only ia64 has this space saving
>> trick in the definition of SMP_CACHE_BYTES ... so it is unsurprising
>> that general users are not following our usage model).
>>
>> How much is this trick saving us?  Static size of data area in
>> vmlinux doesn't change very much as SMP_CACHE_BYTES is varied:
>>
>>    text    data     bss     dec     hex filename
>> 8677481 1139704 1206357 11023542         a834b6 vmlinux-8
>> 8677417 1141808 1206397 11025622         a83cd6 vmlinux-16
>> 8677417 1146000 1206477 11029894         a84d86 vmlinux-32
>> 8677353 1146256 1206573 11030182         a84ea6 vmlinux-64
>> 8677353 1163152 1207085 11047590         a892a6 vmlinux-128
>>
>> I'm not sure how to evaluate dynamic behavior (allocation of
>> structures whose size is dependent on SMP_CACHE_BYTES at
>> runtime).
>>
>> -Tony
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
>--
>Mosberger Consulting LLC, voice/fax: 510-744-9372,
>http://www.mosberger-consulting.com/
>35706 Runckel Lane, Fremont, CA 94536

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel