From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754552Ab0CSBbW (ORCPT ); Thu, 18 Mar 2010 21:31:22 -0400 Received: from mail-bw0-f209.google.com ([209.85.218.209]:40891 "EHLO mail-bw0-f209.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752618Ab0CSBbR (ORCPT ); Thu, 18 Mar 2010 21:31:17 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=Q94spLpj0TmtkGpNHLSK8bTDN6t6IE8XkcgGvTHafDjOmijpUTHYohvfWbzKsfYxW5 Ux70X4xvEVdBzWQ0igsg47ZALa4WlefG9Fc7VGCBYsBsgPBhvUPQFqXTOVhwiGC5F9Hb ERmuSrc5XZtFOAWC7aLbTXOiNCA1I+v4cZZWk= Date: Fri, 19 Mar 2010 02:31:22 +0100 From: Frederic Weisbecker To: David Miller Cc: tj@kernel.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [BUG] percpu misaligned allocation Message-ID: <20100319013119.GB22095@nowhere> References: <20100318044930.GC5045@nowhere> <4BA1F2BA.30604@kernel.org> <20100318.175413.183069013.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100318.175413.183069013.davem@davemloft.net> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 18, 2010 at 05:54:13PM -0700, David Miller wrote: > From: Tejun Heo > Date: Thu, 18 Mar 2010 18:30:34 +0900 > > > > > if (!total_profile_count) { > > - buf = (char *)alloc_percpu(perf_trace_t); > > + buf = (char *)__alloc_percpu(sizeof(perf_trace_t), > > + __alignof__(unsigned long)); > > if (!buf) > > goto fail_buf; > > Why not make perf_trace_t have the proper alignment? So, making perf_trace_t as align(8) would do the trick? I lack the knowledge about alignment layout for archs that need aligned accesses. At a first glance, what I would except is that every buffer has a base address aligned, no? > > That's better than patching around it like this. > > Defining it as an array of char[]'s is just asking > for lots of trouble. Yeah but we need a generic type. This is because our buffer can be of any random type to match all the trace event layouts we have, all of them being generated by macros.