|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfa
To: |
"Tian, Kevin" <kevin.tian@xxxxxxxxx> |
Subject: |
Re: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths" |
From: |
"Luck, Tony" <tony.luck@xxxxxxxxx> |
Date: |
Tue, 22 Nov 2005 08:11: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 10:29:50 +0000 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<571ACEFD467F7749BC50E0A98C17CDD802C069CF@pdsmsx403> |
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> |
References: |
<1132548798.1478.7.camel@xxxxxxxxxxxxxxxxxxxxx> <571ACEFD467F7749BC50E0A98C17CDD802C069CF@pdsmsx403> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Mutt/1.4.1i |
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths", Tian, Kevin
- Re: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths",
Luck, Tony <=
- RE: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths", Tian, Kevin
- RE: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths", Tian, Kevin
- RE: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths", Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths", Luck, Tony
- RE: [Xen-devel] __ia64__ ifdef in xmalloc.c: "Fix ar.unat handling forfast paths", Luck, Tony
|
|
|
|
|