Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1237181pxk; Thu, 10 Sep 2020 10:16:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJytvger3tIM0JbQO2mnHPAc4GluCLf0RCkR8YrtA1MJUNOFmrpquHuT94aytj6yQ9OkWd+K X-Received: by 2002:a17:906:2a49:: with SMTP id k9mr10218137eje.117.1599758161960; Thu, 10 Sep 2020 10:16:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599758161; cv=none; d=google.com; s=arc-20160816; b=sY/sFznViIci8zwA6pkYpDURqixUVM2E4OiN663K9gUSOqzStV17Bpvd7w3DZsnF3q gH88D9Rqmj/Ol6Jtsu/6WtyqrtTPeyiHiwFIjIZSgJ3W6qUjpgtagRCE2YJIfresJTYY dFERM6I0RnNs1J2qYwfSMlrElq6C/b405YAS2Ajm2pURYN3lLP4s4S32R9DdU8GsbhbB BylpYtfGlYkb1KPyPh9dibthzd4m2WrQEAhZDsb5NS2+1dzI9XySpUPct1yqVizxN0VE W64ec2CRADdeCpRygFruGz15hrGDqFCoQsmSZ8dLgQ1emJ1SM9yDB2c8KdQJz1qBYKyJ GEWA== 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=e7jefh25XCKZfPoIkRNxN7N4Tflp0SqsV/tI/tWYRzk=; b=GYn2cgP2ktDXm88AnYnLE3zyscydxbgLhyZPp3E1V1RWK4nmjMED5cyS++kyNz1HmZ C3o4bSZUEl9KZphDNfMc063zXcKU0ATudA3fzwVbYRNj1dvw4oQhvaPfhFX76R8f82jG nJLld6KydqSBmTeIVUPLpdoOXaeW75MTYqyK9hTJTttgrQxY5PxTJdJKo2IrWTDY+H+n NmuoTSlmbl//UO0uu/uj4YFd0w6KGsWrv1wrJXxZggE1OeDbQ8nAXuXPcuhydONWS6HL 74Oilt6ePzRjwkCtK+u4OHXJQ7HIIovPzj8bCFrhPud+hOMPXVKml2hOCQjNAmaWs9ja gBaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=XG1F0moH; 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 g7si4227147edp.272.2020.09.10.10.15.39; Thu, 10 Sep 2020 10:16:01 -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=XG1F0moH; 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 S1726855AbgIJRMy (ORCPT + 99 others); Thu, 10 Sep 2020 13:12:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53386 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726612AbgIJRLf (ORCPT ); Thu, 10 Sep 2020 13:11:35 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D631BC061573 for ; Thu, 10 Sep 2020 10:11:34 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id o5so7546576wrn.13 for ; Thu, 10 Sep 2020 10:11:34 -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=e7jefh25XCKZfPoIkRNxN7N4Tflp0SqsV/tI/tWYRzk=; b=XG1F0moHLQKlC3AzqilBlzA2HA0fK1G/k0lQDl+t35aFaRzrjooU2skfOKLerx6Zpr aU6YzU6ZJZ/zKaE8xcC+nNp0VAcKbPZuR5BZHuXK1f46JHA+yueimFnO63xfUaOObu2B a6KEqTqY8qvD8imR7OJy2tdob5sN4dHzBtqQ9OFtO1alOVwWU8wjmOzFcHO9bjUwDMCP 872eO5nSO78xuXnQhncEZ1VUIIBsbB/7ORAtpx+i3CAvAnubYuxfBiDBrQh0RNYa1vGH pl2FeosyK0AxyAbc10rEw4avzsAxWRxIcKVeMMKiOA8kETxcpqtVxC1B/Uy1nrGlciAA Eetg== 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=e7jefh25XCKZfPoIkRNxN7N4Tflp0SqsV/tI/tWYRzk=; b=kUDg8S6fUWGzMEZ+bpIbwa2iXixlDi+uHF0mkZk2yIDJ2K3bKJK3NKWSeXvCMWVSbB ipHBBrdUwgkuJt6bA3bNcb4hxSM+B8XF7te4BKgHXTPKAPNK26VRrWqO2JE1eslCwYqY E2iTPWqnY3P99e+OMRck9JZ1Y46kNDa7Xrzh4xAc3hnQqy4kvMRLQD80oSm2z1wRSMq0 JpslwVhGW8NXmqeOfcr9S/R4YNAUTPTLKWmqL8Ho/TD+tHQLuxLlMH10AjgtddgWkOJB D3hCNRWM49xkXIqLqTS4rnJa4HqLE32q5HXldQpfcPCNRkwMmt0Mm7kxIsZEdcmAbnZG q5dw== X-Gm-Message-State: AOAM532LME/rRDRD81LMKKIgRm5POzYyMIycjIxqgFQFl7NacMatOR2E VLokipGDqQn/5K0iddA7WQlXp+PI56Tii/JQ0N/KVw== X-Received: by 2002:adf:82b1:: with SMTP id 46mr10891426wrc.271.1599757893281; Thu, 10 Sep 2020 10:11:33 -0700 (PDT) MIME-Version: 1.0 References: <20200908044228.61197-1-namhyung@kernel.org> <20200910155736.jadhmqvnqquammpn@two.firstfloor.org> In-Reply-To: <20200910155736.jadhmqvnqquammpn@two.firstfloor.org> From: Ian Rogers Date: Thu, 10 Sep 2020 10:11:21 -0700 Message-ID: Subject: Re: [PATCHSET 0/4] perf stat: Add --multiply-cgroup option To: Andi Kleen Cc: Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , Ingo Molnar , Peter Zijlstra , Mark Rutland , Alexander Shishkin , Stephane Eranian , LKML 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 Thu, Sep 10, 2020 at 8:57 AM Andi Kleen wrote: > > On Tue, Sep 08, 2020 at 01:42:24PM +0900, Namhyung Kim wrote: > > When we profile cgroup events with perf stat, it's very annoying to > > specify events and cgroups on the command line as it requires the > > mapping between events and cgroups. (Note that perf record can use > > cgroup sampling but it's not usable for perf stat). > > The problem is real, but I don't really like your solution. > The option is ugly. Should rather be solved with some suitable > syntax in the expression parser to express: apply to all, > instead of adding adhoc options like this. > > There are some additional problems that really need to be eventually > solved too: > > - If you use the old syntax and some cgroups are not covered you don't > get any warning. At least that should be fixed too. > > - And of course if everything works it is still very slow for the kernel > because there are so many perf events to handle. Long term we probably > need some more flexible way to just specify for given perf events which set of > cgroups they should apply, so that sharing and low overhead monitoring > of many cgroups is possible I hate to say it, but maybe some eBPF filter > is the solution here. > > -Andi Just to throw in some 2c worth. A nice thing about Namhyung's approach is that it can apply for metrics, events and pfm-events. It would be nice if there were a single option for specifying these, perhaps we can figure one out. One thought that came to mind based on Namhyung's multiply name was and assuming a cgroup could be a modifier: perf record -e cycles:G1 there could be equivalent to a new syntax of lists and multiplies of: perf record -e [cycles]*[:G1] This would allow expressions like: perf record -e [{instructions,cycles},branches]*[:u,:k] which would be equivalent to (showing the effect on sibling groups): perf record -e {instructions:u,cycles:u},branches:u,{instructions:k,cycles:k},branches:k Adding in cgroups makes a longer list of events: perf record -e [{instructions,cycles},branches]*[:u,:k]*[:G1,:G2] becomes: perf record -e {instructions:u:G1,cycles:u:G1},branches:u:G1,{instructions:k:G1,cycles:k:G1},branches:k:G1,{instructions:u:G2,cycles:u:G2},branches:u:G2,{instructions:k:G2,cycles:k:G2},branches:k:G2 This is somewhat similar to Arnaldo's proposal but trying to make things a bit more generic, avoiding overloading the use of sibling groups, .. Perhaps there is a syntax that others prefer or could be borrowed from a familiar source like a programming language. I think for Namhyung's sake it is important not to get too distracted by desires for better syntax, as this change makes a benefit in a way that works with the existing flags. If it is accepted, the man pages need to be updated. Thanks, Ian