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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 45D0CC2B9F4 for ; Mon, 28 Jun 2021 14:37:23 +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 B9A9A61D3B for ; Mon, 28 Jun 2021 14:37:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9A9A61D3B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 0708789CA1; Mon, 28 Jun 2021 14:37:20 +0000 (UTC) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) by gabe.freedesktop.org (Postfix) with ESMTPS id B57CF89CA1 for ; Mon, 28 Jun 2021 14:37:18 +0000 (UTC) Received: by mail-oo1-xc32.google.com with SMTP id v3-20020a4ac9030000b029024c9d0bff49so886016ooq.0 for ; Mon, 28 Jun 2021 07:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=V/saHbRlyOy5ddJuZOY9EHpBakgA7dAfHWaeEThMt6A=; b=h/EzmTXiakdw18lflKTMGoyTqhb7BbYy5aWheTjljmzLSCxfZeuhFORgkFlXmrfyKR D1HKSOQlOMi37w1J44+TDVqChS827up+ez7wvwE2C09swqywP5eEdrGbvjGwfTbJAsup aZQNGpmiVVKbIFp4ZkgvfxqK0uO1904Mqqdl4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=V/saHbRlyOy5ddJuZOY9EHpBakgA7dAfHWaeEThMt6A=; b=GQ+5k95yDZNeL8s0iMvhnXhMCEjxmMeSp/cqAxwB5LY5dTpMNrwuE3H+6eOhnxzuzO pXzKFAFcS4U26ldrOUnJRe/ihi9W4DBBOA/VKgxTjI/NtLZJo5MTDrAXO82MiqFVCq9l BtESuw6yRWLiiAIH7tGNv69MpxkNMUtBdr47yUmwW3HUzxE8YB9HsOGd7HlsGv2jtO5r qwazmD9mW5TDWVij1ohsQMvMWJBJyWhO9kFDFkLUxncNFw4L11eOQUlYVNP9roT5l26o zAuOPbx8aeToMWzbvDgpEJ6pmUwiUAwsi+79TJf4YV3h45lKV6cftuoFbapo5qhlZKCT 4xPQ== X-Gm-Message-State: AOAM530EgQzXCkJdU2R9gU2P5Wy7uBrljD1udl95nguEMnRTMZUag9P4 rMK1B6ExVwTKfCIkdYqvYaISOXrHJDuSESC03zFVqw== X-Google-Smtp-Source: ABdhPJwkjv7kqc9F9YfPK4DKsl3yXpQr+eWXfMKOw7gKDof92VntbnCTRW1jJRcCVsDIX2fPprSKarbGArGf9wR/7bc= X-Received: by 2002:a4a:9b99:: with SMTP id x25mr19638473ooj.85.1624891038030; Mon, 28 Jun 2021 07:37:18 -0700 (PDT) MIME-Version: 1.0 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> <52dc8610-de57-a5a8-9a1d-0efebb29b881@linux.intel.com> In-Reply-To: <52dc8610-de57-a5a8-9a1d-0efebb29b881@linux.intel.com> From: Daniel Vetter Date: Mon, 28 Jun 2021 16:37:06 +0200 Message-ID: Subject: Re: [PATCH 0/7] Per client engine busyness To: Tvrtko Ursulin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 , =?UTF-8?Q?Christian_K=C3=B6nig?= , Maling list - DRI developers , "Nieto, David M" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, Jun 28, 2021 at 12:18 PM Tvrtko Ursulin wrote: > > > > On 14/05/2021 16:10, Christian K=C3=B6nig wrote: > > Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin: > >> > >> On 14/05/2021 15:56, Christian K=C3=B6nig wrote: > >>> Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin: > >>>> > >>>> On 14/05/2021 14:53, Christian K=C3=B6nig 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. If we go with fdinfo for these it becomes clear who all owns the file, since it's then a per-process thing. Not sure how much smarts we should have for internal debugfs output. Maybe one-shot update on first driver ioctl (since if you're on render nodes then X does the drm auth dance, so "first ioctl" is wrong). -Daniel --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch