Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp1397798pxb; Fri, 10 Sep 2021 05:11:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvej5ep/OeuH8277P3lD3Py0yRwSW35C7liXyWPu0YXgsIfkQE/cSXuBeT7MaswanmGXup X-Received: by 2002:a5e:dc0b:: with SMTP id b11mr6549960iok.91.1631275867295; Fri, 10 Sep 2021 05:11:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631275867; cv=none; d=google.com; s=arc-20160816; b=pGqI9Q50RHVfkfXE3TScvMyhgJqxBmvG3ndvbLbz0hkJlArjwJhBCpbpWXgcINbesQ dTnqfyqeFgvMNiQbkeVo+fAR45ceLF0Jct8TRD7Eo9Hv4dETdWRNSp7wP9AmWFa+xJwv ViTKbOCdqDKsbbsn1DPKRbpNNwoskPg1VEv3dJxQxY4lc2rwli+COOO5NkdwibfZk56e IWOXTcLum1tM7dXd28E6FOiH+EWgcg1fL5MDj7iQhHMfeghXIgzY0UT/pdypRLFk+RDy fR40+nEdv/ZWhHpaMvjnHbIZoeeoz3c3GmVtPPo5Tq3eYwQ4zujF1AAMdio3MulcUP2B h3aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=pb1Nmeuk6fmE1u4MF/nb7SoeJbvxphmpweu8NYMXWG0=; b=mm1QRkaveIQLhEOUTcmAjw4ah2ytEoAH1ujjoDRY6+j6Vl8wA5ZsXbbDEAD7JHP4rJ qrUEjYla8wvrAKSiJOkCo69mOm1orIO8OByDwiXCJrSpfT00n/0Htr7fbWmxqkgeeqT6 rbxJ0EqWVBdgU1sphscA9b6R3qBJ+csM30uNQaTcXa0XtiEJRFcb8Tbja+/7eDkX91NQ Krs3MUKAPQ6Q1y33XwYHq0oIOnpoY454Sat+moTvwI7YkE2jCv6dxYqpVz+4oM3skdNp ty2To6mLiAQ4qMTQInGcRp5tjPfytce8sI/4Rmcw7JQuEtBVOssYUE8yzb2vzvRFE12b IIWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=FpyqFjWN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a7si4072982ila.35.2021.09.10.05.10.53; Fri, 10 Sep 2021 05:11:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=FpyqFjWN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233020AbhIJMKk (ORCPT + 99 others); Fri, 10 Sep 2021 08:10:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53922 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232873AbhIJMKg (ORCPT ); Fri, 10 Sep 2021 08:10:36 -0400 Received: from ozlabs.org (ozlabs.org [IPv6:2401:3900:2:1::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CB9EC061574 for ; Fri, 10 Sep 2021 05:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1631275760; bh=pb1Nmeuk6fmE1u4MF/nb7SoeJbvxphmpweu8NYMXWG0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=FpyqFjWNe6GQOwYAFkVnCFD/CJtU/FeJJ8bjdiHqSBdJTXLDo+8lnn3jQ//cQe71v AjZCT4iPZe74NSnCisluphzHZGybROjY+5GpCT56fWjmaz0B1kLbUzwRO7w62FNLcg lpcp2Nen+RMRL+Ka6HnqusUvBwiwVAfBN6Kh/r2WlnbfJbB7F28xMIdfTZMqrP9App ZBsB8Re2jgMejPC+wX56Yo/bQnNf8GD4kKIroTyqbkK3/zoxTTsIyJZ1vtsSnmUQ38 RPvS87awgC+KG1wloKAeXiD8488kCUDqVeqdR15ykQUtNX+oCQGobsfrZoSrtN01RP uArZnch0plSxw== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4H5ZRf6jq5z9sW5; Fri, 10 Sep 2021 22:09:18 +1000 (AEST) From: Michael Ellerman To: Peter Zijlstra , Stephane Eranian Cc: linux-kernel@vger.kernel.org, acme@redhat.com, jolsa@redhat.com, kim.phillips@amd.com, namhyung@kernel.org, irogers@google.com, atrajeev@linux.vnet.ibm.com, maddy@linux.ibm.com Subject: Re: [PATCH v1 01/13] perf/core: add union to struct perf_branch_entry In-Reply-To: <20210909190342.GE4323@worktop.programming.kicks-ass.net> References: <20210909075700.4025355-1-eranian@google.com> <20210909075700.4025355-2-eranian@google.com> <20210909190342.GE4323@worktop.programming.kicks-ass.net> Date: Fri, 10 Sep 2021 22:09:12 +1000 Message-ID: <878s04my3b.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > On Thu, Sep 09, 2021 at 12:56:48AM -0700, Stephane Eranian wrote: >> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h >> index f92880a15645..eb11f383f4be 100644 >> --- a/include/uapi/linux/perf_event.h >> +++ b/include/uapi/linux/perf_event.h >> @@ -1329,13 +1329,18 @@ union perf_mem_data_src { >> struct perf_branch_entry { >> __u64 from; >> __u64 to; >> - __u64 mispred:1, /* target mispredicted */ >> - predicted:1,/* target predicted */ >> - in_tx:1, /* in transaction */ >> - abort:1, /* transaction abort */ >> - cycles:16, /* cycle count to last branch */ >> - type:4, /* branch type */ >> - reserved:40; >> + union { >> + __u64 val; /* to make it easier to clear all fields */ >> + struct { >> + __u64 mispred:1, /* target mispredicted */ >> + predicted:1,/* target predicted */ >> + in_tx:1, /* in transaction */ >> + abort:1, /* transaction abort */ >> + cycles:16, /* cycle count to last branch */ >> + type:4, /* branch type */ >> + reserved:40; >> + }; >> + }; >> }; > > > Hurpmh... all other bitfields have ENDIAN_BITFIELD things except this > one. Power folks, could you please have a look? The bit number of each field changes between big and little endian, but as long as kernel and userspace are the same endian, and both only access values via the bitfields then it works. It's preferable to have the ENDIAN_BITFIELD thing, so that the bit numbers are stable, but we can't change it now without breaking ABI :/ Adding the union risks having code that accesses val and expects to see mispred in bit 0 for example, which it's not on big endian. If it's just for clearing easily we could do that with a static inline that sets all the bitfields. With my compiler here (GCC 10) it's smart enough to just turn it into a single unsigned long store of 0. eg: static inline void clear_perf_branch_entry_flags(struct perf_branch_entry *e) { e->mispred = 0; e->predicted = 0; e->in_tx = 0; e->abort = 0; e->cycles = 0; e->type = 0; e->reserved = 0; } It does look like we have a bug in perf tool though, if I take a perf.data from a big endian system to a little endian one I don't see any of the branch flags decoded. eg: BE: 2413132652524 0x1db8 [0x2d0]: PERF_RECORD_SAMPLE(IP, 0x1): 5279/5279: 0xc00000000045c028 period: 923003 addr: 0 ... branch stack: nr:28 ..... 0: c00000000045c028 -> c00000000dce7604 0 cycles P 0 LE: 2413132652524 0x1db8 [0x2d0]: PERF_RECORD_SAMPLE(IP, 0x1): 5279/5279: 0xc00000000045c028 period: 923003 addr: 0 ... branch stack: nr:28 ..... 0: c00000000045c028 -> c00000000dce7604 0 cycles 0 ^ missing P I guess we're missing a byte swap somewhere. cheers