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 X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D003C433DF for ; Wed, 20 May 2020 16:50:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3C8CB2065F for ; Wed, 20 May 2020 16:50:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Eh6SNc8k" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727067AbgETQu2 (ORCPT ); Wed, 20 May 2020 12:50:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726548AbgETQu1 (ORCPT ); Wed, 20 May 2020 12:50:27 -0400 Received: from mail-yb1-xb44.google.com (mail-yb1-xb44.google.com [IPv6:2607:f8b0:4864:20::b44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 974EFC08C5C0 for ; Wed, 20 May 2020 09:50:27 -0700 (PDT) Received: by mail-yb1-xb44.google.com with SMTP id r128so1311509ybc.6 for ; Wed, 20 May 2020 09:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dKYd+eEqh94+PPSxeT0mEN4CuPeMB4JjYrAni6yKOek=; b=Eh6SNc8kXSnAsUcJ5NDUp1JxID73klNpgan5mB/uvuYRnEWgar9pgqlkZSuIvpsVcJ 5D5oeNsStNFxA5sYJNZ+t216Rv2BDcgEUT+Mhe6/MaxnYjKFV5VEe6GxiBoERmOmBrSG RVtGXez/y2uvR9MXKV3qNOX9QlYr+FXL6PLilyrvR3Ykp4Q2AWMM9PXTjASyVKPeInsW Rs9Ery4sW/GeLu7I76XKp55D0+vk0kEAdXO3YC+5xGkPWviutxFd6lHb9qBEYaHV4dPl vSyLhhI8q5fbkzAwG2N8Uwip8g5oXJfipPY8OlZN9Q6/Wodsd6B81xf5GdR53xHbKpRO qgdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dKYd+eEqh94+PPSxeT0mEN4CuPeMB4JjYrAni6yKOek=; b=GBhdVIKXrQ2zFCiRd0ChjhSHRljd01zP0IEg/363jZm8LAueNgepQeGNhZK6t419Yb jxHPINTopDMmIn+IZIv2khzkcCCyxRRpPR+kC8jlsqg0/MAyOiAO6fFtIwNV/uJqm6ai axgfUHLwJVH7CPAPumsGsL+gOZmS5yJqwCmKggE+XAQFXM8yQOeK6K42cJY9QSnXdd8e hg4jaemcZWzshN0VGxuF/NyotXO8axqTWA1fWzlr0bkv95S8ESQOS/DE2eVUdmpxxz27 sq8PVgpdqeURBYr5PaITjsknvRpUYuAe+YaK/B+VE3iepF9Zbe3NhW5FtOSbrVNWHkPu qTlQ== X-Gm-Message-State: AOAM531dHEVCszmkZMNYDSz5gTLgo9HkQEyWK/lLt5fIHJevr3aSCKtp fYBq+sDwIsEgQnfL/LJ55mwpXvzYhfTa9eux9iIPSQ== X-Google-Smtp-Source: ABdhPJy5M4bW3EQJOtlA1J3fukdU3GsXBm5ahWMZ7f1tynRhLuSFHjlXX7HP519wXpXurP8N9XDEwnsZVT7E1P4g7iM= X-Received: by 2002:a25:790e:: with SMTP id u14mr8671529ybc.324.1589993426351; Wed, 20 May 2020 09:50:26 -0700 (PDT) MIME-Version: 1.0 References: <20200520072814.128267-1-irogers@google.com> <20200520072814.128267-6-irogers@google.com> <20200520134847.GM157452@krava> In-Reply-To: <20200520134847.GM157452@krava> From: Ian Rogers Date: Wed, 20 May 2020 09:50:13 -0700 Message-ID: Subject: Re: [PATCH 5/7] perf metricgroup: Remove duped metric group events To: Jiri Olsa Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Namhyung Kim , Song Liu , Andrii Nakryiko , Kajol Jain , Andi Kleen , John Garry , Jin Yao , Kan Liang , Cong Wang , Kim Phillips , Paul Clarke , Srikar Dronamraju , LKML , Networking , bpf , linux-perf-users , Vince Weaver , Stephane Eranian Content-Type: text/plain; charset="UTF-8" Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, May 20, 2020 at 6:49 AM Jiri Olsa wrote: > > On Wed, May 20, 2020 at 12:28:12AM -0700, Ian Rogers wrote: > > SNIP > > > > > @@ -157,7 +183,7 @@ static int metricgroup__setup_events(struct list_head *groups, > > int i = 0; > > int ret = 0; > > struct egroup *eg; > > - struct evsel *evsel; > > + struct evsel *evsel, *tmp; > > unsigned long *evlist_used; > > > > evlist_used = bitmap_alloc(perf_evlist->core.nr_entries); > > @@ -173,7 +199,8 @@ static int metricgroup__setup_events(struct list_head *groups, > > ret = -ENOMEM; > > break; > > } > > - evsel = find_evsel_group(perf_evlist, &eg->pctx, metric_events, > > + evsel = find_evsel_group(perf_evlist, &eg->pctx, > > + eg->has_constraint, metric_events, > > evlist_used); > > if (!evsel) { > > pr_debug("Cannot resolve %s: %s\n", > > @@ -200,6 +227,12 @@ static int metricgroup__setup_events(struct list_head *groups, > > list_add(&expr->nd, &me->head); > > } > > > > + evlist__for_each_entry_safe(perf_evlist, tmp, evsel) { > > + if (!test_bit(evsel->idx, evlist_used)) { > > + evlist__remove(perf_evlist, evsel); > > + evsel__delete(evsel); > > + } > > is the groupping still enabled when we merge groups? could part > of the metric (events) be now computed in different groups? By default the change will take two metrics and allow the shorter metric (in terms of number of events) to share the events of the longer metric. If the events for the shorter metric aren't in the longer metric then the shorter metric must use its own group of events. If sharing has occurred then the bitmap is used to work out which events and groups are no longer in use. With --metric-no-group then any event can be used for a metric as there is no grouping. This is why more events can be eliminated. With --metric-no-merge then the logic to share events between different metrics is disabled and every metric is in a group. This allows the current behavior to be had. There are some corner cases, such as metrics with constraints (that don't group) and duration_time that is never placed into a group. Partial sharing, with one event in 1 weak event group and 1 in another is never performed. Using --metric-no-group allows something similar. Given multiplexing, I'd be concerned about accuracy problems if events between groups were shared - say for IPC, were you measuring instructions and cycles at the same moment? > I was wondering if we could merge all the hasmaps into single > one before the parse the evlist.. this way we won't need removing > later.. but I did not thought this through completely, so it > might not work at some point This could be done in the --metric-no-group case reasonably easily like the current hashmap. For groups you'd want something like a set of sets of events, but then you'd only be able to share events if the sets were the same. A directed acyclic graph could capture the events and the sharing relationships, it may be possible to optimize cases like {A,B,C}, {A,B,D}, {A,B} so that the small group on the end shares events with both the {A,B,C} and {A,B,D} group. This may be good follow up work. We could also solve this in the json, for example create a "phony" group of {A,B,C,D} that all three metrics share from. You could also use --metric-no-group to achieve that sharing now. Thanks, Ian > jirka >