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 7A060C433ED for ; Wed, 19 May 2021 18:23:27 +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 3A8C761244 for ; Wed, 19 May 2021 18:23:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A8C761244 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=nouveau-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 766346EDAE; Wed, 19 May 2021 18:23:20 +0000 (UTC) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by gabe.freedesktop.org (Postfix) with ESMTPS id 48C0689C37 for ; Wed, 19 May 2021 18:23:18 +0000 (UTC) Received: by mail-ot1-x32f.google.com with SMTP id t10-20020a05683022eab0290304ed8bc759so12568583otc.12 for ; Wed, 19 May 2021 11:23: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; bh=lU1aEp1/fTDg1MRFhbbvBQJlurTqZag3+kwKZCaFfEA=; b=BJw5L3BrtVFBrlK/Uqaiei75sqgQvSftM6vbSEuAeMCnAOJSgXijp70aaA796HngQq 7Dz0QD4n2CB/dAa7pcIsA+Lj68SO0UcRPLCC9/vCA47p62qUZrSxVcXjWL/xpXr7KPNm mX8/aOaR7tz62Y55+iGjltsTTXjfpkkq6aC2M= 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; bh=lU1aEp1/fTDg1MRFhbbvBQJlurTqZag3+kwKZCaFfEA=; b=GRJ37XVQLMEVE46MTTLSYjVVhI1H/AseVWtU6wyBsmtrSgq3yZoNW3w38fTaRAikdL h50lFQDpM8ouilIRr4CcqZUC42qwBSHM0JGqSyZ2XvR/9Mu58cQNLi0pWoRCjGlnAjgi wy9tobREMF/dUykOMO+mcOqYnxlp0/IsWLAJMa1QasmZnF05/OBaNfqwwPgV2Mp3m8yi kjJi0GgY6QDw5gF0mLoYIi/qDOEigJWKe7FJPuM7hQ8gI56EtD84TGm69LTfjykzTpT8 5n5GcYPosG0YDE0Z7zJq3z/MZORf5MLZSY4GZJibtH1yVQ9PBLttBgMdt+6O8RjLMb2a e2Kg== X-Gm-Message-State: AOAM5330Tk+QIglAY7zcbkc/igGadAdUMTKIS56o4wR2IGNGpigDd8Zs F89xeQpPDbQBERKfMpa/A+f8NqRUr/uSA/BOfTQlQA== X-Google-Smtp-Source: ABdhPJyU9K6L5sHxQhmxWQ79rVoGsktJYOokpWHkHDpmUhbMtFnKZa/uvMA9fJL0vSohClns0xfEnyFTtv5rJekj8aA= X-Received: by 2002:a05:6830:1155:: with SMTP id x21mr598773otq.303.1621448597285; Wed, 19 May 2021 11:23:17 -0700 (PDT) MIME-Version: 1.0 References: <6cf2f14a-6a16-5ea3-d307-004faad4cc79@linux.intel.com> <7f8fc38a-cd25-aa1f-fa2d-5d3334edb3d2@linux.intel.com> <71428a10-4b2f-dbbf-7678-7487f9eda6a5@linux.intel.com> In-Reply-To: From: Daniel Vetter Date: Wed, 19 May 2021 20:23:05 +0200 Message-ID: To: Tvrtko Ursulin Subject: Re: [Nouveau] [Intel-gfx] [PATCH 0/7] Per client engine busyness X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel Graphics Development , Maling list - DRI developers , Daniel Stone , Simon Ser , "nouveau@lists.freedesktop.org" , "Koenig, Christian" , "Nieto, David M" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin wrote: > > > On 18/05/2021 10:40, Tvrtko Ursulin wrote: > > > > On 18/05/2021 10:16, Daniel Stone wrote: > >> Hi, > >> > >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin > >> wrote: > >>> I was just wondering if stat(2) and a chrdev major check would be a > >>> solid criteria to more efficiently (compared to parsing the text > >>> content) detect drm files while walking procfs. > >> > >> Maybe I'm missing something, but is the per-PID walk actually a > >> measurable performance issue rather than just a bit unpleasant? > > > > Per pid and per each open fd. > > > > As said in the other thread what bothers me a bit in this scheme is that > > the cost of obtaining GPU usage scales based on non-GPU criteria. > > > > For use case of a top-like tool which shows all processes this is a > > smaller additional cost, but then for a gpu-top like tool it is somewhat > > higher. > > To further expand, not only cost would scale per pid multiplies per open > fd, but to detect which of the fds are DRM I see these three options: > > 1) Open and parse fdinfo. > 2) Name based matching ie /dev/dri/.. something. > 3) Stat the symlink target and check for DRM major. stat with symlink following should be plenty fast. > All sound quite sub-optimal to me. > > Name based matching is probably the least evil on system resource usage > (Keeping the dentry cache too hot? Too many syscalls?), even though > fundamentally I don't it is the right approach. > > What happens with dup(2) is another question. We need benchmark numbers showing that on anything remotely realistic it's an actual problem. Until we've demonstrated it's a real problem we don't need to solve it. E.g. top with any sorting enabled also parses way more than it displays on every update. It seems to be doing Just Fine (tm). > Does anyone have any feedback on the /proc//gpu idea at all? When we know we have a problem to solve we can take a look at solutions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau 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 4BB9EC433ED for ; Wed, 19 May 2021 18:23: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 95B73611BF for ; Wed, 19 May 2021 18:23:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 95B73611BF 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 406816E20F; Wed, 19 May 2021 18:23:20 +0000 (UTC) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4986989CC9 for ; Wed, 19 May 2021 18:23:18 +0000 (UTC) Received: by mail-ot1-x32b.google.com with SMTP id u25-20020a0568302319b02902ac3d54c25eso12635514ote.1 for ; Wed, 19 May 2021 11:23: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; bh=lU1aEp1/fTDg1MRFhbbvBQJlurTqZag3+kwKZCaFfEA=; b=BJw5L3BrtVFBrlK/Uqaiei75sqgQvSftM6vbSEuAeMCnAOJSgXijp70aaA796HngQq 7Dz0QD4n2CB/dAa7pcIsA+Lj68SO0UcRPLCC9/vCA47p62qUZrSxVcXjWL/xpXr7KPNm mX8/aOaR7tz62Y55+iGjltsTTXjfpkkq6aC2M= 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; bh=lU1aEp1/fTDg1MRFhbbvBQJlurTqZag3+kwKZCaFfEA=; b=ID2n/4vx11Wzg2lRB0ExgCM2wQ6RrvwdwSJAA5aNIpNwIyyiGl2lZvGJlvzR/4RTd4 sAmPhRn3Xy33yCjTKd/j3vKK5w3rNTI7kD1TDZn4qyQMnbsoilHxwGQgxK3g7j/t8mKo RvD9ep2FZw/wgCxphm2Xn8swhV6Br3yeUUjDhm2JQUYFGRPj1pFwpkkmmG7Ww2trJSVw NQnPg/dwWIYQj/CFx+/umha/SqGPwvUIUgZsjjd76R3ds1Tpoq0VlYdZORUQWzLIFmLE xMPWiUJ7f9CO1T4TipsL4hG9+yZKNzAN9dXRQh8MIKzeta9iw6sLbB0qZA3If2yzZZuQ MzUA== X-Gm-Message-State: AOAM5334GL7Jd2gbgwJV8KRyL335rWjt7qob8G/sjTBn8HgOi0b2qsHo KON+lFaKRH+Hbze4S3MtZAfK433Y+IdJU4pBYYaNoA== X-Google-Smtp-Source: ABdhPJyU9K6L5sHxQhmxWQ79rVoGsktJYOokpWHkHDpmUhbMtFnKZa/uvMA9fJL0vSohClns0xfEnyFTtv5rJekj8aA= X-Received: by 2002:a05:6830:1155:: with SMTP id x21mr598773otq.303.1621448597285; Wed, 19 May 2021 11:23:17 -0700 (PDT) MIME-Version: 1.0 References: <6cf2f14a-6a16-5ea3-d307-004faad4cc79@linux.intel.com> <7f8fc38a-cd25-aa1f-fa2d-5d3334edb3d2@linux.intel.com> <71428a10-4b2f-dbbf-7678-7487f9eda6a5@linux.intel.com> In-Reply-To: From: Daniel Vetter Date: Wed, 19 May 2021 20:23:05 +0200 Message-ID: Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness To: Tvrtko Ursulin Content-Type: text/plain; charset="UTF-8" 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: "jhubbard@nvidia.com" , Intel Graphics Development , Maling list - DRI developers , "nouveau@lists.freedesktop.org" , "Koenig, Christian" , "aritger@nvidia.com" , "Nieto, David M" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin wrote: > > > On 18/05/2021 10:40, Tvrtko Ursulin wrote: > > > > On 18/05/2021 10:16, Daniel Stone wrote: > >> Hi, > >> > >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin > >> wrote: > >>> I was just wondering if stat(2) and a chrdev major check would be a > >>> solid criteria to more efficiently (compared to parsing the text > >>> content) detect drm files while walking procfs. > >> > >> Maybe I'm missing something, but is the per-PID walk actually a > >> measurable performance issue rather than just a bit unpleasant? > > > > Per pid and per each open fd. > > > > As said in the other thread what bothers me a bit in this scheme is that > > the cost of obtaining GPU usage scales based on non-GPU criteria. > > > > For use case of a top-like tool which shows all processes this is a > > smaller additional cost, but then for a gpu-top like tool it is somewhat > > higher. > > To further expand, not only cost would scale per pid multiplies per open > fd, but to detect which of the fds are DRM I see these three options: > > 1) Open and parse fdinfo. > 2) Name based matching ie /dev/dri/.. something. > 3) Stat the symlink target and check for DRM major. stat with symlink following should be plenty fast. > All sound quite sub-optimal to me. > > Name based matching is probably the least evil on system resource usage > (Keeping the dentry cache too hot? Too many syscalls?), even though > fundamentally I don't it is the right approach. > > What happens with dup(2) is another question. We need benchmark numbers showing that on anything remotely realistic it's an actual problem. Until we've demonstrated it's a real problem we don't need to solve it. E.g. top with any sorting enabled also parses way more than it displays on every update. It seems to be doing Just Fine (tm). > Does anyone have any feedback on the /proc//gpu idea at all? When we know we have a problem to solve we can take a look at solutions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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 5B818C433B4 for ; Wed, 19 May 2021 18:23:22 +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 8E375611BF for ; Wed, 19 May 2021 18:23:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E375611BF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch 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 87B346EE46; Wed, 19 May 2021 18:23:20 +0000 (UTC) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by gabe.freedesktop.org (Postfix) with ESMTPS id 48DC589C6C for ; Wed, 19 May 2021 18:23:18 +0000 (UTC) Received: by mail-ot1-x32c.google.com with SMTP id d25-20020a0568300459b02902f886f7dd43so12599494otc.6 for ; Wed, 19 May 2021 11:23: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; bh=lU1aEp1/fTDg1MRFhbbvBQJlurTqZag3+kwKZCaFfEA=; b=BJw5L3BrtVFBrlK/Uqaiei75sqgQvSftM6vbSEuAeMCnAOJSgXijp70aaA796HngQq 7Dz0QD4n2CB/dAa7pcIsA+Lj68SO0UcRPLCC9/vCA47p62qUZrSxVcXjWL/xpXr7KPNm mX8/aOaR7tz62Y55+iGjltsTTXjfpkkq6aC2M= 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; bh=lU1aEp1/fTDg1MRFhbbvBQJlurTqZag3+kwKZCaFfEA=; b=eVYXzNqA3GaNy9kkkFQRIPB08rX9KKAAZwaoKyKET2Aheh4rhrSAw1Gd7USkRTYeGJ AL8kxsywcFCHOf53L3AbWyLGwiMh3BWvcL5p0qHGl/YC0exZIKnVdduzbhKcFlvL92HK 3Z3nONcjFCrNfNZh8YL2gywZu6vske5f58dVkATGkOwzfN46nk31uB1g84HgcatwTaeq iTSoF5RRiTqemOcq42QVSzNATBxOqrNfn2qSs8Xo8H16rb3gSa9EKFIMMvkdi3sBUxC9 x4i/12A6CntG3UrNiNJ0AUAbVS7gM+cx0yqKhMQJ4ErcN6Z9QzxRnVAl0ETjib7sWtFe MiTQ== X-Gm-Message-State: AOAM530YyPVj9CRe4w9HJz+8Th7EpKs2QgUtZ1bT1uN2cmtYbPRYlHWq jzOmuOaIdes+iO13p9MTTgnJqKH8LZUTeToXc3EzOg== X-Google-Smtp-Source: ABdhPJyU9K6L5sHxQhmxWQ79rVoGsktJYOokpWHkHDpmUhbMtFnKZa/uvMA9fJL0vSohClns0xfEnyFTtv5rJekj8aA= X-Received: by 2002:a05:6830:1155:: with SMTP id x21mr598773otq.303.1621448597285; Wed, 19 May 2021 11:23:17 -0700 (PDT) MIME-Version: 1.0 References: <6cf2f14a-6a16-5ea3-d307-004faad4cc79@linux.intel.com> <7f8fc38a-cd25-aa1f-fa2d-5d3334edb3d2@linux.intel.com> <71428a10-4b2f-dbbf-7678-7487f9eda6a5@linux.intel.com> In-Reply-To: From: Daniel Vetter Date: Wed, 19 May 2021 20:23:05 +0200 Message-ID: To: Tvrtko Ursulin 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: "jhubbard@nvidia.com" , Intel Graphics Development , Maling list - DRI developers , Simon Ser , "nouveau@lists.freedesktop.org" , "Koenig, Christian" , "aritger@nvidia.com" , "Nieto, David M" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, May 19, 2021 at 6:16 PM Tvrtko Ursulin wrote: > > > On 18/05/2021 10:40, Tvrtko Ursulin wrote: > > > > On 18/05/2021 10:16, Daniel Stone wrote: > >> Hi, > >> > >> On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin > >> wrote: > >>> I was just wondering if stat(2) and a chrdev major check would be a > >>> solid criteria to more efficiently (compared to parsing the text > >>> content) detect drm files while walking procfs. > >> > >> Maybe I'm missing something, but is the per-PID walk actually a > >> measurable performance issue rather than just a bit unpleasant? > > > > Per pid and per each open fd. > > > > As said in the other thread what bothers me a bit in this scheme is that > > the cost of obtaining GPU usage scales based on non-GPU criteria. > > > > For use case of a top-like tool which shows all processes this is a > > smaller additional cost, but then for a gpu-top like tool it is somewhat > > higher. > > To further expand, not only cost would scale per pid multiplies per open > fd, but to detect which of the fds are DRM I see these three options: > > 1) Open and parse fdinfo. > 2) Name based matching ie /dev/dri/.. something. > 3) Stat the symlink target and check for DRM major. stat with symlink following should be plenty fast. > All sound quite sub-optimal to me. > > Name based matching is probably the least evil on system resource usage > (Keeping the dentry cache too hot? Too many syscalls?), even though > fundamentally I don't it is the right approach. > > What happens with dup(2) is another question. We need benchmark numbers showing that on anything remotely realistic it's an actual problem. Until we've demonstrated it's a real problem we don't need to solve it. E.g. top with any sorting enabled also parses way more than it displays on every update. It seems to be doing Just Fine (tm). > Does anyone have any feedback on the /proc//gpu idea at all? When we know we have a problem to solve we can take a look at solutions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx