From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7BF04C433FE for ; Mon, 13 Dec 2021 22:06:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243433AbhLMWG5 (ORCPT ); Mon, 13 Dec 2021 17:06:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239831AbhLMWGz (ORCPT ); Mon, 13 Dec 2021 17:06:55 -0500 Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0D76C06173F for ; Mon, 13 Dec 2021 14:06:55 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id s11so16297038ilv.3 for ; Mon, 13 Dec 2021 14:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zTPn8auGutn38LvbgcksVlp70zD3zIxdnxqFAr/xw18=; b=UdsKx5QAwKAV6vhCEmgcG/KiXBU89WcrU9K87mz06/QwqRIxE2MRNPdp90VlGq1K6q 1Q1FdyAzVQIIGrHmuR48JEDsdFZETrOFmhKpC7Q7LesjrCsCsGwQmKHDC5hQaOb6xWzz vAbkXts4r8QbWQHBtlC0bFOkwTKcomEu2zjuT2ocTCQe2t/wPooUm7rE5qhpNjCdWYPP D35i0fu9ijrF0q1COAKePyofG5XwTOtInwbIP/pijUrbOfbt43UEiWIRGLhbxWw1r/N/ VFdnegr3b5dQqqQpW1z6v7MMH3OnhGGIt9hPgwKGyHaADtKEAw3x5XDDB+w43aN/8G7b 0AiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zTPn8auGutn38LvbgcksVlp70zD3zIxdnxqFAr/xw18=; b=gk3FOKQy0AZtkovSmI4ppROAuDQJtIXgsEccgvAzG0JgtqNqb7H1cwVXWbrYASY8+G KDKlg/rknhpU7bO0suwaF3lVWqYO4RvMMCuFfRyKK384Fdu/pRwnXhU63iGd2WQdVMLY HIz5CC4TLFDVIyoeafbIh7CecO9BbC8w9jdGEB88lqHl0tydoNvv0MM3vAWxLFXTtQ7w nPtEyIkSVwHxaF3nUyAs8w8exQ4D/wwnrnci5Ousyyi8MIxxh/UMcAPonN7DKTxb2esx By97+hSmXExlwYGGe2eJlEjbKDmnifukZb0npY6VSgyPxGV/gBy0gjxDIK5LtBGfrSM/ rErw== X-Gm-Message-State: AOAM531GAUewH9+Hdg5OQgVcXnhUrRvK+xMhBi7PUDpJ9Gd+SdVkLbnP upYwO7+f/iqxuBay4bd6YA8wb0CLOHMzpGh8rPY6OQ== X-Google-Smtp-Source: ABdhPJyhSyitxMBa16ebH4CTLm7N7+9UX1SAFoyjyVTUuKqfFMLJg1lVmWnS1g/w6yifUHT3I1BSdBZH/ytTfpR/FOw= X-Received: by 2002:a05:6e02:168a:: with SMTP id f10mr904394ila.2.1639433214840; Mon, 13 Dec 2021 14:06:54 -0800 (PST) MIME-Version: 1.0 References: <20211208024607.1784932-1-irogers@google.com> In-Reply-To: From: Ian Rogers Date: Mon, 13 Dec 2021 14:06:43 -0800 Message-ID: Subject: Re: [PATCH 00/22] Refactor perf cpumap To: James Clark Cc: eranian@google.com, Andi Kleen , Jiri Olsa , Namhyung Kim , John Garry , Kajol Jain , "Paul A . Clarke" , Arnaldo Carvalho de Melo , Riccardo Mancini , Kan Liang , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, Vineet Singh , Mathieu Poirier , Suzuki K Poulose , Mike Leach , Leo Yan , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 13, 2021 at 8:10 AM Ian Rogers wrote: > > On Mon, Dec 13, 2021 at 3:39 AM James Clark wrote: > > > > > > > > On 08/12/2021 02:45, Ian Rogers wrote: > > > Perf cpu map has various functions where a cpumap and index are passed > > > in order to load the cpu. A problem with this is that the wrong index > > > may be passed for the cpumap, causing problems like aggregation on the > > > wrong CPU: > > > https://lore.kernel.org/lkml/20211204023409.969668-1-irogers@google.com/ > > > > > > This patch set refactors the cpu map API, greatly reducing it and > > > explicitly passing the cpu (rather than the pair) to functions that > > > need it. Comments are added at the same time. > > > > > > Ian Rogers (22): > > > libperf: Add comments to perf_cpu_map. > > > perf stat: Add aggr creators that are passed a cpu. > > > perf stat: Switch aggregation to use for_each loop > > > perf stat: Switch to cpu version of cpu_map__get > > > perf cpumap: Switch cpu_map__build_map to cpu function > > > perf cpumap: Remove map+index get_socket > > > perf cpumap: Remove map+index get_die > > > perf cpumap: Remove map+index get_core > > > perf cpumap: Remove map+index get_node > > > perf cpumap: Add comments to aggr_cpu_id > > > perf cpumap: Remove unused cpu_map__socket > > > perf cpumap: Simplify equal function name. > > > perf cpumap: Rename empty functions. > > > perf cpumap: Document cpu__get_node and remove redundant function > > > perf cpumap: Remove map from function names that don't use a map. > > > perf cpumap: Remove cpu_map__cpu, use libperf function. > > > perf cpumap: Refactor cpu_map__build_map > > > perf cpumap: Rename cpu_map__get_X_aggr_by_cpu functions > > > perf cpumap: Move 'has' function to libperf > > > perf cpumap: Add some comments to cpu_aggr_map > > > perf cpumap: Trim the cpu_aggr_map > > > perf stat: Fix memory leak in check_per_pkg > > > > > > tools/lib/perf/cpumap.c | 7 +- > > > tools/lib/perf/include/internal/cpumap.h | 9 +- > > > tools/lib/perf/include/perf/cpumap.h | 1 + > > > tools/perf/arch/arm/util/cs-etm.c | 16 +- > > > tools/perf/builtin-ftrace.c | 2 +- > > > tools/perf/builtin-sched.c | 6 +- > > > tools/perf/builtin-stat.c | 273 ++++++++++++----------- > > > tools/perf/tests/topology.c | 10 +- > > > tools/perf/util/cpumap.c | 182 ++++++--------- > > > tools/perf/util/cpumap.h | 102 ++++++--- > > > tools/perf/util/cputopo.c | 2 +- > > > tools/perf/util/env.c | 6 +- > > > tools/perf/util/stat-display.c | 69 +++--- > > > tools/perf/util/stat.c | 9 +- > > > tools/perf/util/stat.h | 3 +- > > > 15 files changed, 361 insertions(+), 336 deletions(-) > > > > > > > For the whole set: > > > > Reviewed-by: James Clark > > > > I didn't see any obvious issues with mixing up aggregation modes or CPU/idx types. Also > > gave perf stat a test in the different modes and didn't see an issue. > > > > But I'm wondering if it's possible to go further and add a struct around the CPU int so that the > > compiler checks for correctness instead. It still seems quite easy to mix up index and > > CPU, for example these functions are subtly different, but both use int: > > > > LIBPERF_API int perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx); > > LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, int cpu); > > > > Something like this would make it impossible to make a mistake: > > > > struct cpu { int cpu }; > > > > I mean it's more of a coincidence that CPUs can be identified by an integer, but they are more > > of an object than an integer, so it could make sense to wrap it. But maybe it could be quite > > cumbersome to use and be overkill. > > Thanks James! I am working on a v2 patch set and will have a go at > adding this to the end. > > Ian I was checking on the style issues around wrapping an int with a struct, and it is preferred style to enforce strict type checking (by way of an old post): https://lore.kernel.org/all/ancug3$iq1$1@penguin.transmeta.com/ Thanks, Ian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8F274C433F5 for ; Mon, 13 Dec 2021 22:37:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZYBa/XQCyq/xfCcKLcfzEhjsDxbdbeYCvWTJzy+BPIs=; b=e9XTJ5HUvlLjJg h6uCGkrYMzR54WMiIcs0awNzqbr43QSmo5yPJe2p4Kg5udRHTEoA/+haNFkdY9d+yZHDaF9ZrBYy6 cUVSjn/f9GWg2n61JAdtknfpsKreULrguQXWWI+1LzmgX5PRjHmtMZXaRMpeQMb1a3b7Zp1H9gm2T R6Me0xxtVkZWqqb/PyZdMGqnPN0U/QPm+NhMqZFURKjGf66n3BBckPuNkA87KTHT0uhMJZZyUTE1h 6XaSOILODTAFEuykrN53eT4jN9hp3LkZqm/ntuVvhqDCgHBORSAIx7NLmxwX0FQAS1JM7qUviSDC7 mXciZB+IUqoowGArf0zQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mwtuR-00BmQM-OI; Mon, 13 Dec 2021 22:35:04 +0000 Received: from mail-il1-x129.google.com ([2607:f8b0:4864:20::129]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mwtTF-00Bbcb-Vn for linux-arm-kernel@lists.infradead.org; Mon, 13 Dec 2021 22:06:59 +0000 Received: by mail-il1-x129.google.com with SMTP id o13so951282ilt.12 for ; Mon, 13 Dec 2021 14:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zTPn8auGutn38LvbgcksVlp70zD3zIxdnxqFAr/xw18=; b=UdsKx5QAwKAV6vhCEmgcG/KiXBU89WcrU9K87mz06/QwqRIxE2MRNPdp90VlGq1K6q 1Q1FdyAzVQIIGrHmuR48JEDsdFZETrOFmhKpC7Q7LesjrCsCsGwQmKHDC5hQaOb6xWzz vAbkXts4r8QbWQHBtlC0bFOkwTKcomEu2zjuT2ocTCQe2t/wPooUm7rE5qhpNjCdWYPP D35i0fu9ijrF0q1COAKePyofG5XwTOtInwbIP/pijUrbOfbt43UEiWIRGLhbxWw1r/N/ VFdnegr3b5dQqqQpW1z6v7MMH3OnhGGIt9hPgwKGyHaADtKEAw3x5XDDB+w43aN/8G7b 0AiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zTPn8auGutn38LvbgcksVlp70zD3zIxdnxqFAr/xw18=; b=hnVgmM4lDmFq01W4ZD+gk5v+Ct7BaTrft2tKAbxUIFmUarXET6R+JWREYTmpu4I8f6 ZbFD5866KzaLkFwDC4syROsFe3TpctPAtzwc0PG8N9yOfk3GiJJwPfAPGsY5/8ORed9g H1KZuL6WH0/6DSri0DZeXEsQuzI6gkrugOjCSx66e9DuJ0GJ4CLnl91aClFSxLKLAj94 V2LnTZWhoOy3e+E7vrwL8ysDMGE2FOkff36isyinBfsAAXQZLNAkiL9VWdRzh0oY6pXN g6hKoswGpufcjSzwiI338LPpblc92qo97UyWgMLW3AfMAjIMGX2qQ+vDRLxE7TzoBT8n C+iQ== X-Gm-Message-State: AOAM5333AO0IvZX2LttpumXbBIYhJ+swXUgSYVPGhlzWIwGvFuJ/prR3 ZyehPtWME3CmpKYK1PSSojJZfd1uJNrQriuoWLXcFQ== X-Google-Smtp-Source: ABdhPJyhSyitxMBa16ebH4CTLm7N7+9UX1SAFoyjyVTUuKqfFMLJg1lVmWnS1g/w6yifUHT3I1BSdBZH/ytTfpR/FOw= X-Received: by 2002:a05:6e02:168a:: with SMTP id f10mr904394ila.2.1639433214840; Mon, 13 Dec 2021 14:06:54 -0800 (PST) MIME-Version: 1.0 References: <20211208024607.1784932-1-irogers@google.com> In-Reply-To: From: Ian Rogers Date: Mon, 13 Dec 2021 14:06:43 -0800 Message-ID: Subject: Re: [PATCH 00/22] Refactor perf cpumap To: James Clark Cc: eranian@google.com, Andi Kleen , Jiri Olsa , Namhyung Kim , John Garry , Kajol Jain , "Paul A . Clarke" , Arnaldo Carvalho de Melo , Riccardo Mancini , Kan Liang , Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, Vineet Singh , Mathieu Poirier , Suzuki K Poulose , Mike Leach , Leo Yan , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211213_140658_077147_52100DAD X-CRM114-Status: GOOD ( 38.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Dec 13, 2021 at 8:10 AM Ian Rogers wrote: > > On Mon, Dec 13, 2021 at 3:39 AM James Clark wrote: > > > > > > > > On 08/12/2021 02:45, Ian Rogers wrote: > > > Perf cpu map has various functions where a cpumap and index are passed > > > in order to load the cpu. A problem with this is that the wrong index > > > may be passed for the cpumap, causing problems like aggregation on the > > > wrong CPU: > > > https://lore.kernel.org/lkml/20211204023409.969668-1-irogers@google.com/ > > > > > > This patch set refactors the cpu map API, greatly reducing it and > > > explicitly passing the cpu (rather than the pair) to functions that > > > need it. Comments are added at the same time. > > > > > > Ian Rogers (22): > > > libperf: Add comments to perf_cpu_map. > > > perf stat: Add aggr creators that are passed a cpu. > > > perf stat: Switch aggregation to use for_each loop > > > perf stat: Switch to cpu version of cpu_map__get > > > perf cpumap: Switch cpu_map__build_map to cpu function > > > perf cpumap: Remove map+index get_socket > > > perf cpumap: Remove map+index get_die > > > perf cpumap: Remove map+index get_core > > > perf cpumap: Remove map+index get_node > > > perf cpumap: Add comments to aggr_cpu_id > > > perf cpumap: Remove unused cpu_map__socket > > > perf cpumap: Simplify equal function name. > > > perf cpumap: Rename empty functions. > > > perf cpumap: Document cpu__get_node and remove redundant function > > > perf cpumap: Remove map from function names that don't use a map. > > > perf cpumap: Remove cpu_map__cpu, use libperf function. > > > perf cpumap: Refactor cpu_map__build_map > > > perf cpumap: Rename cpu_map__get_X_aggr_by_cpu functions > > > perf cpumap: Move 'has' function to libperf > > > perf cpumap: Add some comments to cpu_aggr_map > > > perf cpumap: Trim the cpu_aggr_map > > > perf stat: Fix memory leak in check_per_pkg > > > > > > tools/lib/perf/cpumap.c | 7 +- > > > tools/lib/perf/include/internal/cpumap.h | 9 +- > > > tools/lib/perf/include/perf/cpumap.h | 1 + > > > tools/perf/arch/arm/util/cs-etm.c | 16 +- > > > tools/perf/builtin-ftrace.c | 2 +- > > > tools/perf/builtin-sched.c | 6 +- > > > tools/perf/builtin-stat.c | 273 ++++++++++++----------- > > > tools/perf/tests/topology.c | 10 +- > > > tools/perf/util/cpumap.c | 182 ++++++--------- > > > tools/perf/util/cpumap.h | 102 ++++++--- > > > tools/perf/util/cputopo.c | 2 +- > > > tools/perf/util/env.c | 6 +- > > > tools/perf/util/stat-display.c | 69 +++--- > > > tools/perf/util/stat.c | 9 +- > > > tools/perf/util/stat.h | 3 +- > > > 15 files changed, 361 insertions(+), 336 deletions(-) > > > > > > > For the whole set: > > > > Reviewed-by: James Clark > > > > I didn't see any obvious issues with mixing up aggregation modes or CPU/idx types. Also > > gave perf stat a test in the different modes and didn't see an issue. > > > > But I'm wondering if it's possible to go further and add a struct around the CPU int so that the > > compiler checks for correctness instead. It still seems quite easy to mix up index and > > CPU, for example these functions are subtly different, but both use int: > > > > LIBPERF_API int perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx); > > LIBPERF_API bool perf_cpu_map__has(const struct perf_cpu_map *map, int cpu); > > > > Something like this would make it impossible to make a mistake: > > > > struct cpu { int cpu }; > > > > I mean it's more of a coincidence that CPUs can be identified by an integer, but they are more > > of an object than an integer, so it could make sense to wrap it. But maybe it could be quite > > cumbersome to use and be overkill. > > Thanks James! I am working on a v2 patch set and will have a go at > adding this to the end. > > Ian I was checking on the style issues around wrapping an int with a struct, and it is preferred style to enforce strict type checking (by way of an old post): https://lore.kernel.org/all/ancug3$iq1$1@penguin.transmeta.com/ Thanks, Ian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel