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=-4.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 BE6E3C433ED for ; Tue, 18 May 2021 09:35:20 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5FA4561042 for ; Tue, 18 May 2021 09:35:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5FA4561042 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BE5266EB14; Tue, 18 May 2021 09:35:16 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id CD8766EB11; Tue, 18 May 2021 09:35:14 +0000 (UTC) IronPort-SDR: rQsRkW33nW32PXMr/kAkVZjHgeekp53l2G1A6wR5yCt9RQn8BYZMaJiitez+R9/YFq0I69yhK7 Lv8K2I+n9ipw== X-IronPort-AV: E=McAfee;i="6200,9189,9987"; a="197582682" X-IronPort-AV: E=Sophos;i="5.82,309,1613462400"; d="scan'208";a="197582682" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 02:35:14 -0700 IronPort-SDR: uKmRdx1/EI/UVVCwjRGlBhKhRAz1gQOlOekevTFjEdkqYCA3YpJMuVrpRyTRYHxrzdSS+npi+t 7ifq4XAzq05A== X-IronPort-AV: E=Sophos;i="5.82,309,1613462400"; d="scan'208";a="438583048" Received: from alirazas-mobl.ger.corp.intel.com (HELO [10.213.211.104]) ([10.213.211.104]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 May 2021 02:35:12 -0700 To: "Nieto, David M" , Daniel Vetter , "Koenig, Christian" References: <39ccc2ef-05d1-d9f0-0639-ea86bef58b80@amd.com> <7d6d09fe-ec85-6aaf-9834-37a49ec7d6c5@linux.intel.com> <9144f63b-953d-2019-742d-6553e09f5b40@amd.com> <22e7d6ea-f2dd-26da-f264-b17aad25af95@linux.intel.com> <6cf2f14a-6a16-5ea3-d307-004faad4cc79@linux.intel.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: Date: Tue, 18 May 2021 10:35:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alex Deucher , Intel Graphics Development , Maling list - DRI developers Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On 17/05/2021 19:02, Nieto, David M wrote: > [AMD Official Use Only] > = > = > The format is simple: > = > : % Hm what time period does the percent relate to? The i915 implementation uses accumulated nanoseconds active. That way = who reads the file can calculate the percentage relative to the time = period between two reads of the file. > we also have entries for the memory mapped: > mem : KiB Okay so in general key values per line in text format. Colon as delimiter. What common fields could be useful between different drivers and what = common naming scheme, in order to enable as easy as possible creation of = a generic top-like tool? driver: pdev: ring-: N ... mem-: N ... What else? Is ring a good common name? We actually more use engine in i915 but I am = not really bothered about it. Aggregated GPU usage could be easily and generically done by userspace = by adding all rings and normalizing. > On my submission = > https://lists.freedesktop.org/archives/amd-gfx/2021-May/063149.html = > =A0I = > added a python script to print out the info. It has a CPU usage lower = > that top, for example. > = > To be absolutely honest, I agree that there is an overhead, but It might = > not be as much as you fear. For me more the issue is that the extra number of operations grows with = the number of open files on the system, which has no relation to the = number of drm clients. Extra so if the monitoring tool wants to show _only_ DRM processes. Then = the cost scales with total number of processes time total number of = files on the server. This design inefficiency bothers me yes. This is somewhat alleviated by = the proposal from Chris = (https://patchwork.freedesktop.org/patch/419042/?series=3D86692&rev=3D1) = although there are downsides there as well. Like needing to keep a map = of pids to drm files in drivers. Btw what do you do in that tool for same fd in a multi-threaded process or so? Do you show duplicate entries or detect and ignore? I guess I did = not figure out if you show by pid/tgid or by fd. Regards, Tvrtko > ------------------------------------------------------------------------ > *From:* Tvrtko Ursulin > *Sent:* Monday, May 17, 2021 9:00 AM > *To:* Nieto, David M ; Daniel Vetter = > ; Koenig, Christian > *Cc:* Alex Deucher ; Intel Graphics Development = > ; Maling list - DRI developers = > > *Subject:* Re: [PATCH 0/7] Per client engine busyness > = > On 17/05/2021 15:39, Nieto, David M wrote: >> [AMD Official Use Only] >> = >> = >> Maybe we could try to standardize how the different submission ring = >>=A0 =A0usage gets exposed in the fdinfo? We went the simple way of just = >> adding name and index, but if someone has a suggestion on how else we = >> could format them so there is commonality across vendors we could just = >> amend those. > = > Could you paste an example of your format? > = > Standardized fdinfo sounds good to me in principle. But I would also > like people to look at the procfs proposal from Chris, > =A0 - link to which I have pasted elsewhere in the thread. > = > Only potential issue with fdinfo I see at the moment is a bit of an > extra cost in DRM client discovery (compared to my sysfs series and also > procfs RFC from Chris). It would require reading all processes (well > threads, then maybe aggregating threads into parent processes), all fd > symlinks, and doing a stat on them to figure out which ones are DRM devic= es. > = > Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers. > = >> I=92d really like to have the process managers tools display GPU usage = >> regardless of what vendor is installed. > = > Definitely. > = > Regards, > = > Tvrtko _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx