[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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).
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
> 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,
35706 Runckel Lane, Fremont, CA 94536
Xen-devel mailing list