Received: by 2002:a05:6a10:5594:0:0:0:0 with SMTP id ee20csp438986pxb; Mon, 25 Apr 2022 13:18:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzMeUTQ8vk+JtVhvgyJDHqBZEmB0ZGCb4MkcHe+mPF35H58B8iIGhQluRYAOpNr0tidN6bT X-Received: by 2002:a17:902:7049:b0:156:285a:2d64 with SMTP id h9-20020a170902704900b00156285a2d64mr20024361plt.63.1650917880539; Mon, 25 Apr 2022 13:18:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650917880; cv=none; d=google.com; s=arc-20160816; b=wItT2lR3nVhvDsMXi+typMlh6fAaureyj/elplVJAw0n49y8/xGhZjfL/f3SzexcrQ iy5lhMUg4T4kVwlL1MWQyBT9oPEgjThDczS476F3dwCdOz87KEW5cSHKlFGNkwDJ8rQw MWTmyXWFjiw1pu3Asth5stDXQjHIIAcvhK9/9WGUmHfemxBF/2xF7z9LF2lMFc5vGDIA gG54TicyGdmQviEGmTKyY/YhSRmdz9cHOfBN9LMcntbA9R3aQ5NMrOFqYoREUFbYmfi8 lYECs9X/OWEUQ0lQjVaJLcqGMFEa52Rdf9ufU1nT7AaS3b1QAyYzdRtHSW6pMjYPqUtD F9xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=1RWly8sd7d8QeY693RwMY0EPR+uMtvTexbsydzgQnqc=; b=vkEpkyIHPXcNyK/wYS7f4YUePjar8au0ZXg6ds6OLTgfMl9r4y+WN+pVTnPA2Vwgkt CHsfBODXsuKtJJ3+BLfz9UVrTauT2pWBfLvvu/tk0UzfHxofGKdofJVzRnChWimSKUNO WVItnC1B7Lp1XclxApAzLFqUn+XPgUbYAxOsp7jsINDcXmCQuXCgJdIxlfwxkg9r6IsZ zFlHHf2AnFm5CYMJSpjTij8wGwzuImQLKewUVpa8O08D+d5OLZuPPSBpIyjOPZv5Fwfl 3JZxsw/RnfpxTSKaaRmNkzNFA0x5kXlNz7xQs7Np6v2yn0vZZuQw90r6IYS9hf7zWGyi B8dA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=D3xhXPdv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h7-20020a636c07000000b003aa193ba520si15435642pgc.365.2022.04.25.13.17.42; Mon, 25 Apr 2022 13:18:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=D3xhXPdv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244730AbiDYTKM (ORCPT + 99 others); Mon, 25 Apr 2022 15:10:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235701AbiDYTKL (ORCPT ); Mon, 25 Apr 2022 15:10:11 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67A9523BC3; Mon, 25 Apr 2022 12:07:06 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id t25so27914590lfg.7; Mon, 25 Apr 2022 12:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1RWly8sd7d8QeY693RwMY0EPR+uMtvTexbsydzgQnqc=; b=D3xhXPdv2YvHfaWlGmDiw1VHNflMWXOyMgJ3FJZzVuqatITEPlZjbNSmUQ704Lx4/S u/p1f3uX5f2yrgz7dURzivu2lTtIHSFMr2dVcFe38wVtChTeGUD58LKwS86yzyciqITA J1SIQmN7tag8YN0S+YaSxKILd3kxcPDQep5TqySwcQA13ClugAGKo8u7sopM3+Zn0v8F 7KLnfagruoRL6vpDH1paSm4xv4GUrOyAiis0PGfYEQiaZSZJKRnNH2BZfxTM3czLP4o4 EzcUfns0WK9KhjG4OCgvQmlIbfDLa42oIiAIYKt9DaiTge1mx3/cnys5/WQq0dHg394e XRow== 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=1RWly8sd7d8QeY693RwMY0EPR+uMtvTexbsydzgQnqc=; b=X+CoLsDD33I1N/oeCeM4ILolnMKG5etWrRuB3bx1XLARksbcnEbXReXdg+qryFxAcm S4etWd6wVhJ/QgGAhxwsD0Tmvs/xuSi/MOPkJJ3bsNSPmeZuW6MeSjPjd8aPL9oKIslr 4tpAyMj5durhLCSq0LcI7zpua6BYwh3zLzodbQu/TdsJITCaAqNB3fa/Bvr4LeqoYeMj 9g2X0UEap70JwLCYggNi0BUFzi9LF6I39dyDc2JJksagCpCwBh2kfkJMnpTgsaYbbsyj VpWi9iPlpkFwa5GG4X2NzZHemPohhtZxRGHhuqdF7OFBpo3ks6j+pb/5t4bCfQldPIwQ Yffg== X-Gm-Message-State: AOAM531emnATTrUOB5rp5iLjUhLjqnhfkHdcFGjXbY2afwtzguwEMJTq lgdBMXF0HD8OKFBldnI7HQtdf+hd+MEHH+oe7S4= X-Received: by 2002:a05:6512:39cf:b0:471:ea64:70cb with SMTP id k15-20020a05651239cf00b00471ea6470cbmr12124971lfu.47.1650913624575; Mon, 25 Apr 2022 12:07:04 -0700 (PDT) MIME-Version: 1.0 References: <20220420102354.468173-1-florian.fischer@muhq.space> <20220423121557.z5gzbqadonmrg6ef@pasture> In-Reply-To: <20220423121557.z5gzbqadonmrg6ef@pasture> From: Namhyung Kim Date: Mon, 25 Apr 2022 12:06:53 -0700 Message-ID: Subject: Re: [PATCHSET v4 next 0/3] perf stat: add user_time and system_time tool events To: Florian Fischer Cc: Arnaldo Carvalho de Melo , linux-perf-users , Ian Rogers , Xing Zhengjun , linux-kernel , Peter Zijlstra , Ingo Molnar Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 23, 2022 at 5:16 AM Florian Fischer wrote: > > On 22.04.2022 16:52, Namhyung Kim wrote: > > Hello, > > > > On Fri, Apr 22, 2022 at 3:05 PM Arnaldo Carvalho de Melo > > wrote: > > > > > > Em Wed, Apr 20, 2022 at 12:23:51PM +0200, Florian Fischer escreveu: > > > > This patch series adds new internal events to perf stat exposing the times spend > > > > in user and kernel mode in nanoseconds reported by rusage. > > > > > > > > During some benchmarking using perf it bothered me that I could not easily > > > > retrieve those times from perf stat when using the machine readable output. > > > > > > > > But perf definitely knows about those values because in the human readable output > > > > they are present. > > > > > > > > Therefore I exposed the times reported by rusage via the new tool events: > > > > user_time and system_time. > > > > > > > > This allows to retrieved them in machine-readable output: > > > > > > > > $ ./perf stat -x, -e duration_time,user_time,system_time,cache-misses -- grep -q -r duration_time tools/perf > > > > 72134524,ns,duration_time:u,72134524,100.00,, > > > > 65225000,ns,user_time:u,65225000,100.00,, > > > > 6865000,ns,ssystem_time:u,6865000,100.00,, > > Anyway it looks a little bit strange to me if we can get > > system time in user mode only (the 'u' modifier). > > Sorry but I don't really understand what you mean. > The system_time is reported to userspace via rusage filled by wait4(2). > It will always report the value reported to the user space regardless of what > counters perf has access to. > > If you run perf as user you get the same system_time (but with the ':u' suffix) > as when you run perf as root or lower kernel.perf_event_paranoid to allow access > to more counters. The ':u' modifier means that the event should count only in user mode. So I think system_time:u should be 0 by definition. Likewise, user_time:k should be handled as such. But as I said before, we already have the task-clock event, so it's not clear why we need this too. Also these tool events won't work for other use cases like perf record. Thanks, Namhyung