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

>From: Rusty Russell
>Sent: 2005年11月21日 12:53
>Hi all,
>
>	While browsing the code, I noticed this in xmalloc.c:
>
>#ifndef __ia64__
>    BUG_ON(align > SMP_CACHE_BYTES);
>#endif
>
>	This is clearly wrong: due to header alignment we cannot give you a
>greater alignment than SMP_CACHE_BYTES.  Overriding this will cause the
>allocation to succeed, but not give the alignment requested.  It usually
>indicates the caller should be fixed.
>
>Does someone with an ia64 box know why, or want to rip it out and see
>what breaks?
>
>Thanks!
>Rusty.
>--
>A bad analogy is like a leaky screwdriver -- Richard Braakman
>

I didn't note that ifdef before, and removing it doesn't break dom0. I doubt the reason from following definition which is copied from Linux directly into Xen:

#ifdef CONFIG_SMP
# define SMP_CACHE_SHIFT	L1_CACHE_SHIFT
# define SMP_CACHE_BYTES	L1_CACHE_BYTES
#else
  /*
   * The "aligned" directive can only _increase_ alignment, so this is
   * safe and provides an easy way to avoid wasting space on a
   * uni-processor:
   */
# define SMP_CACHE_SHIFT	3
# define SMP_CACHE_BYTES	(1 << 3)
#endif

For a UP system, SMP_CACHE_BYTES is only 8 bytes to save space. Then maybe several months ago, there's such requirement to xmalloc a 16bytes aligned (legal on ia64 system like a long double) structure and then failed due to BUG_ON with an immediate lazy hack to add ifdef there. For now, such case seems disappearing after a quick test.

However I think the preferred way is to increase SMP_CACHE_SHIFT to 4 to match maximum allowed alignment value. But I'm not sure from the comment above why "3" is defined there on native linux. CC to linux-ia64 list for standard answer. ;-)

Thanks,
Kevin
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html