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 76027C49EA3 for ; Mon, 28 Jun 2021 10:18:25 +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 1E34C61C6A for ; Mon, 28 Jun 2021 10:18:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E34C61C6A 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 7BA286E419; Mon, 28 Jun 2021 10:18:21 +0000 (UTC) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by gabe.freedesktop.org (Postfix) with ESMTPS id A2D8B6E417; Mon, 28 Jun 2021 10:18:19 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10028"; a="293561775" X-IronPort-AV: E=Sophos;i="5.83,305,1616482800"; d="scan'208";a="293561775" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2021 03:18:19 -0700 X-IronPort-AV: E=Sophos;i="5.83,305,1616482800"; d="scan'208";a="419117739" Received: from sankeeth-mobl.ger.corp.intel.com (HELO [10.213.225.79]) ([10.213.225.79]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2021 03:18:17 -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> <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: <52dc8610-de57-a5a8-9a1d-0efebb29b881@linux.intel.com> Date: Mon, 28 Jun 2021 11:16:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: 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 16:10, Christian König wrote: > Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin: >> >> On 14/05/2021 15:56, Christian König wrote: >>> Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: >>>> >>>> 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. >>> >>> Well I just double checked and that is not correct. >>> >>> Could be that i915 has some special code for that, but on my laptop I >>> only see the X server under the "clients" debugfs file. >> >> Yes we have special code in i915 for this. Part of this series we are >> discussing here. > > Ah, yeah you should mention that. Could we please separate that into > common code instead? Cause I really see that as a bug in the current > handling independent of the discussion here. What we do in i915 is update the pid and name when a task different to the one which opened the fd does a GEM context create ioctl. Moving that to DRM core would be along the lines of doing the same check and update on every ioctl. Maybe allow the update to be one time only if that would work. Would this be desirable and acceptable? If so I can definitely sketch it out. Regards, Tvrtko