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,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 A633EC43460 for ; Mon, 17 May 2021 16:00:46 +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 6C65C60FE7 for ; Mon, 17 May 2021 16:00:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6C65C60FE7 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 698F06E9E4; Mon, 17 May 2021 16:00:43 +0000 (UTC) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id A175B6E7EC; Mon, 17 May 2021 16:00:41 +0000 (UTC) IronPort-SDR: Rwu8LEL8geFPFDgbMhD7vSif8sG/YwVfAHeNzuAPrUodmYU/xnGFI3DwHOoXG5wHj37wwHWmTE 2i3NLlJpakCg== X-IronPort-AV: E=McAfee;i="6200,9189,9987"; a="187903062" X-IronPort-AV: E=Sophos;i="5.82,307,1613462400"; d="scan'208";a="187903062" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2021 09:00:39 -0700 IronPort-SDR: kdjFSQqaxvTsGlFLY+WSp7phdjhF5XzUoRM45Bo3pvvZXzI3BM3XqrNOnnEqHTXcnHME3DamXT lEccz0QwxzBQ== X-IronPort-AV: E=Sophos;i="5.82,307,1613462400"; d="scan'208";a="438037020" Received: from lobrie3x-mobl4.ger.corp.intel.com (HELO [10.213.193.103]) ([10.213.193.103]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2021 09:00:37 -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: Mon, 17 May 2021 17:00:34 +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 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