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

[Dave Anderson]

Keir Fraser wrote:
> On 7/10/08 14:39, "Dave Anderson" <anderson at redhat.com> 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