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 35B55C433B4 for ; Tue, 18 May 2021 09:35:17 +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 ED4B461073 for ; Tue, 18 May 2021 09:35:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED4B461073 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=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 36A046EB11; 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 Subject: Re: [PATCH 0/7] Per client engine busyness 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-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel Graphics Development , Maling list - DRI developers Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 >  I > 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=86692&rev=1) 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 >>   usage 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, >   - 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 devices. > > Btw is DRM_MAJOR 226 consider uapi? I don't see it in uapi headers. > >> I’d really like to have the process managers tools display GPU usage >> regardless of what vendor is installed. > > Definitely. > > Regards, > > Tvrtko 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