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 74B04C433ED for ; Fri, 14 May 2021 14:48:08 +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 206986144C for ; Fri, 14 May 2021 14:48:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 206986144C 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 B83796EEA4; Fri, 14 May 2021 14:48:05 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2722A6EE92; Fri, 14 May 2021 14:48:04 +0000 (UTC) IronPort-SDR: 745Oo6WW2EW8f5losdSw6ekC3VxojCD+7FPOUP+W6A+pIVn48wnh0udLR4YMKqDZTCYa01G7vb l+Sqqcpq3ahw== X-IronPort-AV: E=McAfee;i="6200,9189,9984"; a="180462124" X-IronPort-AV: E=Sophos;i="5.82,300,1613462400"; d="scan'208";a="180462124" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2021 07:47:59 -0700 IronPort-SDR: mC2DvXEUs543hvkL18nurt6sOyfXYFqMKfR7c+clY/viw2nbDL40cR+gKQXFg0WCvKeAvAnEdI gAcW+JfUzlgA== X-IronPort-AV: E=Sophos;i="5.82,300,1613462400"; d="scan'208";a="393654702" Received: from ankitsi2-mobl.ger.corp.intel.com (HELO [10.213.242.91]) ([10.213.242.91]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 May 2021 07:47:57 -0700 Subject: Re: [PATCH 0/7] Per client engine busyness To: =?UTF-8?Q?Christian_K=c3=b6nig?= , "Nieto, David M" , Alex Deucher References: <20210513110002.3641705-1-tvrtko.ursulin@linux.intel.com> <39ccc2ef-05d1-d9f0-0639-ea86bef58b80@amd.com> <7d6d09fe-ec85-6aaf-9834-37a49ec7d6c5@linux.intel.com> <9144f63b-953d-2019-742d-6553e09f5b40@amd.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: <22e7d6ea-f2dd-26da-f264-b17aad25af95@linux.intel.com> Date: Fri, 14 May 2021 15:47:55 +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: <9144f63b-953d-2019-742d-6553e09f5b40@amd.com> Content-Type: text/plain; charset=utf-8; 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 14/05/2021 14:53, Christian König wrote: >> >> David also said that you considered sysfs but were wary of exposing >> process info in there. To clarify, my patch is not exposing sysfs >> entry per process, but one per open drm fd. >> > > Yes, we discussed this as well, but then rejected the approach. > > To have useful information related to the open drm fd you need to > related that to process(es) which have that file descriptor open. Just > tracking who opened it first like DRM does is pretty useless on modern > systems. We do update the pid/name for fds passed over unix sockets. > But an "lsof /dev/dri/renderD128" for example does exactly what top does > as well, it iterates over /proc and sees which process has that file open. Lsof is quite inefficient for this use case. It has to open _all_ open files for _all_ processes on the system to find a handful of ones which may have the DRM device open. > So even with sysfs aid for discovery you are back to just going over all > files again. For what use case? To enable GPU usage in top we can do much better than iterate over all open files in the system. We can start with a process if going with the /proc proposal, or with the opened DRM file directly with the sysfs proposal. Both are significantly fewer than total number of open files across all processes. Regards, Tvrtko