Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp820500ybk; Fri, 15 May 2020 14:39:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxB9TAk0MYZoaURBNGQOmUqWj7eqhG30Ocq9AGlr19zmT4juuSAWhaOwXK3Gak2eJ6AGWNy X-Received: by 2002:a17:906:7e15:: with SMTP id e21mr4923627ejr.106.1589578790101; Fri, 15 May 2020 14:39:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589578790; cv=none; d=google.com; s=arc-20160816; b=tm2J3N8zicPaX2olrmvK1Pom68bkUmmYTb/OYHzOJv9BCqfKAm4F5WGI/JcbYzTVzi VbNEOnRSm0qBTWxDz1IxKqHtIiI9NJZgO9GuEUK6SMIE7coWtZx5m8Lk4hzMzi6hCSBf u8rgbOaX160sk4bZ0UXLILbPxZZ8Tbrtt6dpgQmde13S/86UgPKe/ENEmfuK7UvAUcIP VAA9Uk5BmAyQ0S/GRzMBsOMy/VAPTZhzBwR1HmHWBzkbQETOl1NXZrXEJaD92NbyCc0u 7JF3b5wqgT1OrX7OzAau7k/zkVitCb7aQJxAOysliTIG554BGRwSgs6OtpT5lrhsy0DK bzaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=sVQVIr84sLsAtEf+Ll1fioJb9v8WVaNtHmGOv4kP0R8=; b=VbXdjyBb9UOZDPQDdCKT0zykjUiOARFl2AYkeHrbtkqnr+0G9ZIykQuFxp4C77pe6E lyDko9LZmAOtKJlDnDtPLrrk8+vGPHqyF2PpitaE+GIprPNXyQOqyqWTOlMiTU8MDb0I /Xv1gKSsWEW2N58nTiEYhbogpKrtSUocJwH7teJo/KSkfty1sGJ4MDIo5dE0+cA8JTrq PWcCXDCbfo4u8hywDWZuyvWwR7gPITe/RLX9+p2o8L6///hsGAYSOA7cC99cZN2wmUTc S+afxS2+3XKzlV4i/74M/W3LvXxrTpoe/mhWqabe22NEw1rvGgTN6VTQTAdNvxpPcrZD BegA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=NfimAyTC; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g2si1080602edf.29.2020.05.15.14.39.27; Fri, 15 May 2020 14:39:50 -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=@google.com header.s=20161025 header.b=NfimAyTC; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727059AbgEOVf4 (ORCPT + 99 others); Fri, 15 May 2020 17:35:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726228AbgEOVf4 (ORCPT ); Fri, 15 May 2020 17:35:56 -0400 Received: from mail-yb1-xb42.google.com (mail-yb1-xb42.google.com [IPv6:2607:f8b0:4864:20::b42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F22E4C05BD0A for ; Fri, 15 May 2020 14:35:55 -0700 (PDT) Received: by mail-yb1-xb42.google.com with SMTP id o8so1841702ybc.11 for ; Fri, 15 May 2020 14:35:55 -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=sVQVIr84sLsAtEf+Ll1fioJb9v8WVaNtHmGOv4kP0R8=; b=NfimAyTC/aIkfOHS2ufqPSllOkeKqp1ZK6kze94gN6kn1ADBKZD3dHs2eXsMiGzBR1 15TmsMiq4KlpeHxxUJ5YdLeKyW23BftJ/gMJmVwlsAn9wcJ8hNxPhlPYwpt5prr5Plzx X43QaZjtrMfGtVTJ/ubc6mkEj6Ge5py3FKjasFZ+0KDaHQnCgsGN1GjqHijFAE+tqSUr I0o2HfrLoen8lac1vJSzfPD+hjfINdbvGmnNZ+aYkTJtddLFqxcCrbqe6UPzgZVuVVHV xDLercuanoXp8rDUc6rnzIa3P8yb045tTQv7jF96E3NAAxmFtOEQvwlMc35NBfkuYpr+ Seqg== 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=sVQVIr84sLsAtEf+Ll1fioJb9v8WVaNtHmGOv4kP0R8=; b=XjxWbISpn+ZkzMhjIuVHSa+N9vHLiwL7kj3JtUQkkGYFfoUIThRYtnVrqriALozZ6v 8CZRVU8zUDPQH7uZ5ONBJH5UC5UX4W3ZxRbP7sNB01QIVtYpZYhIPEtpBUqWFFZP3+nr v6vYkmjXaokqgEqGCLbjBWVcY2UvVzNjbfvTJoD0BTG92bDS5QAMt1Xfl1GYaRPiJPsF JuHlPjdU45gv0XNKywr3UV5wlcUlTSREmCBY99Ym2eO+F3rhUvFYpolnOOp/6S8zEeNw D7xx52PxFY/heCZdGSdWvbnjOYMEF4zJiZGl0mITSFIszQuDvPvPgoq6Jem01rCh1xE4 dmQQ== X-Gm-Message-State: AOAM533hJNMRdn37pcTFI8wAx6cDc/fZhrm5Oz7c+bUKruETzktPSPuZ AjaYdh0fgSPPUEC71e2+aufQ+/ASAaHa3ypwIL/i0Q== X-Received: by 2002:a25:d450:: with SMTP id m77mr9073716ybf.177.1589578554699; Fri, 15 May 2020 14:35:54 -0700 (PDT) MIME-Version: 1.0 References: <20200515165007.217120-1-irogers@google.com> <20200515165007.217120-8-irogers@google.com> <20200515194115.GA3577540@krava> In-Reply-To: <20200515194115.GA3577540@krava> From: Ian Rogers Date: Fri, 15 May 2020 14:35:43 -0700 Message-ID: Subject: Re: [PATCH v2 7/7] perf expr: Migrate expr ids table to a hashmap To: Jiri Olsa Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Namhyung Kim , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , Andrii Nakryiko , John Fastabend , KP Singh , Kajol Jain , Andi Kleen , John Garry , Jin Yao , Kan Liang , Cong Wang , Kim Phillips , Adrian Hunter , Leo Yan , LKML , Networking , bpf , Stephane Eranian Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 15, 2020 at 12:41 PM Jiri Olsa wrote: > > On Fri, May 15, 2020 at 09:50:07AM -0700, Ian Rogers wrote: > > SNIP > > > diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c > > index b071df373f8b..37be5a368d6e 100644 > > --- a/tools/perf/util/metricgroup.c > > +++ b/tools/perf/util/metricgroup.c > > @@ -85,8 +85,7 @@ static void metricgroup__rblist_init(struct rblist *metric_events) > > > > struct egroup { > > struct list_head nd; > > - int idnum; > > - const char **ids; > > + struct expr_parse_ctx pctx; > > const char *metric_name; > > const char *metric_expr; > > const char *metric_unit; > > @@ -94,19 +93,21 @@ struct egroup { > > }; > > > > static struct evsel *find_evsel_group(struct evlist *perf_evlist, > > - const char **ids, > > - int idnum, > > + struct expr_parse_ctx *pctx, > > struct evsel **metric_events, > > bool *evlist_used) > > { > > struct evsel *ev; > > - int i = 0, j = 0; > > bool leader_found; > > + const size_t idnum = hashmap__size(&pctx->ids); > > + size_t i = 0; > > + int j = 0; > > + double *val_ptr; > > > > evlist__for_each_entry (perf_evlist, ev) { > > if (evlist_used[j++]) > > continue; > > - if (!strcmp(ev->name, ids[i])) { > > + if (hashmap__find(&pctx->ids, ev->name, (void **)&val_ptr)) { > > hum, you sure it's doing the same thing as before? > > hashmap__find will succede all the time in here, while the > previous code was looking for the start of the group ... > the logic in here is little convoluted, so maybe I'm > missing some point in here ;-) If we have a metric like "A + B" and another like "C / D" then by we'll generate a string (the extra_events strbuf in the code) like "{A,B}:W,{C,D}:W" from __metricgroup__add_metric. This will turn into an evlist in metricgroup__parse_groups of A,B,C,D. The code is trying to associate the events A,B with the first metric and C,D with the second. The code doesn't support sharing of events and events are marked as used and can't be part of other metrics. The evlist order is also reflective of the order of metrics, so if there were metrics "A + B + C" and "A + B", as the first metric is first in the evlist we don't run the risk of C being placed with A and B in a different group. The old code used the order of events to match within a metric and say for metric "A+B+C" we want to match A then B, and so on. The new code acts more like a set, so "A + B + C" becomes a set containing A, B and C, we check A is in the set then B and then C. For both pieces of code they are only working because of the evlist_used "bitmap" and that the order in the evlists and metrics matches. The current code could just use ordering to match first n1 events with the first metric, the next n2 events with the second and so on. So both the find now, and the strcmp before always return true in this branch. In the RFC patch set I want to share events and so I do checks related to the group leader so that I know when moving from one group to another in the evlist. The find/strcmp becomes load bearing as I will re-use events as long as they match. https://lore.kernel.org/lkml/20200508053629.210324-14-irogers@google.com/ > jirka > > > if (!metric_events[i]) > > metric_events[i] = ev; > > i++; > > @@ -118,7 +119,8 @@ static struct evsel *find_evsel_group(struct evlist *perf_evlist, > > memset(metric_events, 0, > > sizeof(struct evsel *) * idnum); This re-check was unnecessary in the old code and unnecessary even more so now as the hashmap_find is given exactly the same arguments. I'll remove it in v3 while addressing Andrii's memory leak fixes. Thanks, Ian > > - if (!strcmp(ev->name, ids[i])) { > > + if (hashmap__find(&pctx->ids, ev->name, > > + (void **)&val_ptr)) { > > if (!metric_events[i]) > > metric_events[i] = ev; > > SNIP >