Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751997AbdHVSVJ (ORCPT ); Tue, 22 Aug 2017 14:21:09 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:53809 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751815AbdHVSVI (ORCPT ); Tue, 22 Aug 2017 14:21:08 -0400 Date: Tue, 22 Aug 2017 20:21:01 +0200 From: Peter Zijlstra To: "Liang, Kan" Cc: "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "acme@kernel.org" , "jolsa@redhat.com" , "tglx@linutronix.de" , "eranian@google.com" , "ak@linux.intel.com" Subject: Re: [PATCH V5] perf: Add PERF_SAMPLE_PHYS_ADDR Message-ID: <20170822182101.GM32112@worktop.programming.kicks-ass.net> References: <1502993843-6837-1-git-send-email-kan.liang@intel.com> <20170822165638.GH32112@worktop.programming.kicks-ass.net> <37D7C6CF3E00A74B8858931C1DB2F0775378A2C0@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F0775378A2C0@SHSMSX103.ccr.corp.intel.com> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2657 Lines: 47 On Tue, Aug 22, 2017 at 05:58:34PM +0000, Liang, Kan wrote: > It looks there is still one room in cacheline 1. > > So this is very unfortunate... > > > > struct perf_sample_data { > > u64 addr; /* 0 8 */ > > struct perf_raw_record * raw; /* 8 8 */ > > struct perf_branch_stack * br_stack; /* 16 8 */ > > u64 period; /* 24 8 */ > > u64 weight; /* 32 8 */ > > u64 txn; /* 40 8 */ > > union perf_mem_data_src data_src; /* 48 8 */ > > u64 type; /* 56 8 */ You mean @type, right? That is unconditionally used by the output code. > > /* --- cacheline 1 boundary (64 bytes) --- */ > > u64 ip; /* 64 8 */ > > struct { > > u32 pid; /* 72 4 */ > > u32 tid; /* 76 4 */ > > } tid_entry; /* 72 8 */ > > u64 time; /* 80 8 */ > > u64 id; /* 88 8 */ > > u64 stream_id; /* 96 8 */ > > struct { > > u32 cpu; /* 104 4 */ > > u32 reserved; /* 108 4 */ > > } cpu_entry; /* 104 8 */ > > struct perf_callchain_entry * callchain; /* 112 8 */ > > struct perf_regs regs_user; /* 120 16 */ > > /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */ > > struct pt_regs regs_user_copy; /* 136 168 */ > > /* --- cacheline 4 boundary (256 bytes) was 48 bytes ago --- */ > > struct perf_regs regs_intr; /* 304 16 */ > > /* --- cacheline 5 boundary (320 bytes) --- */ > > u64 stack_user_size; /* 320 8 */ > > > > /* size: 384, cachelines: 6, members: 19 */ > > /* padding: 56 */ > > }; Now, I was hoping, that if you move the entire thing into generic code (PPC also support PERF_SAMPLE_DATA) then we can avoid the init here and rely on perf_sample_prepare().