From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Re: [Crash-utility] xencrash fixes for xen-3.3.0 Date: Tue, 07 Oct 2008 16:01:46 +0100 Message-ID: References: <48EB73B9.7000004@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48EB73B9.7000004@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dave Anderson Cc: xen-devel@lists.xensource.com, "Discussion list for crash utility usage, maintenance and development" List-Id: xen-devel@lists.xenproject.org On 7/10/08 15:35, "Dave Anderson" wrote: >> 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? PERCPU_SHIFT has to be big enough that the per-cpu data area happens to be smaller than 1<