Re: [Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0

[Dave Anderson <anderson@xxxxxxxxxx>]

Keir Fraser wrote:
> On 7/10/08 14:39, "Dave Anderson" <anderson@xxxxxxxxxx> wrote:
>
> > The patch looks OK.  But just for sanity's sake, is it guaranteed that
> > the per_cpu data section will be greater than 4k on both architectures?
> > Or could there be some combination of xen CONFIG options that could
> > reduce the i386 per_cpu data section contents to less than 4K even though
> > PERCPU_SHIFT is 13?
> PERCPU_SHIFT has only ever been 12 or 13 so far, and it's unlikely to ever
> get smaller. Ongoing, we could help you out by defining some useful label in
> our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or
> '__per_cpu_start + PERCPU_SHIFT', as I'm not sure about creating labels
> outside the virtual address ranges defined by the object file).
>
>  -- Keir
Yep, that's fine too, but for now Oda-san's patch will suffice now as
long as the smallest possible percpu data section on the x86 arch with
a PERCPU_SHIFT of 13 will always overflow into a space greater than 4k.
So I'm still curious, because I note that on a RHEL5 x86_64 hypervisor
the per-cpu data space is 1576 bytes, and presumably smaller on an x86.
Was there a new data structure that forced the issue?  And does it force
the issue on both arches?

Dave






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