WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "David Mosberger-Tang" <David.Mosberger@xxxxxxx>, "Luck, Tony" <tony.luck@xxxxxxxxx>
Subject: RE: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths"
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 23 Nov 2005 10:58:18 +0800
Cc: djm@xxxxxxxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-ia64@xxxxxxxxxxxxxxx, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tony Breeds <tony@xxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 23 Nov 2005 02:58:30 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXvm8ioGtC0uSx8QIWsyP6Fm0EmgAAPUEgg
Thread-topic: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths"
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