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 E24E0C2B9F7 for ; Mon, 24 May 2021 10:48:07 +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 9E6D7610C7 for ; Mon, 24 May 2021 10:48:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E6D7610C7 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 A9F9E6E19B; Mon, 24 May 2021 10:48:06 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5929B6E190; Mon, 24 May 2021 10:48:05 +0000 (UTC) IronPort-SDR: kB8vCDuLWipRcZwnT/2jZXG9OR/WUOkTJEgSAnUAyoUxNCeoAOwqs4bM7FJg3soFRI0ad4whtS k/rjRrFG6EIw== X-IronPort-AV: E=McAfee;i="6200,9189,9993"; a="181544376" X-IronPort-AV: E=Sophos;i="5.82,319,1613462400"; d="scan'208";a="181544376" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 May 2021 03:48:04 -0700 IronPort-SDR: QuEnAfZ5/WIeo3m+UEXFblrExKUADwlP9aJSrqDHvReibVvmxIJCm/OBqO5uyGflOOKgDPu+dc Y6pL8dPMhDpg== X-IronPort-AV: E=Sophos;i="5.82,319,1613462400"; d="scan'208";a="413543179" Received: from gtenuto-mobl1.ger.corp.intel.com (HELO [10.213.210.116]) ([10.213.210.116]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 May 2021 03:48:02 -0700 Subject: Re: [Intel-gfx] [PATCH 0/7] Per client engine busyness From: Tvrtko Ursulin To: Daniel Vetter 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> Organization: Intel Corporation UK Plc Message-ID: <74dd3086-13c5-2fb0-bb66-eec1a061e693@linux.intel.com> Date: Mon, 24 May 2021 11:48:00 +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=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: "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 20/05/2021 09:35, Tvrtko Ursulin wrote: > On 19/05/2021 19:23, Daniel Vetter wrote: >> 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. > > Maybe. I don't think my point about keeping the dentry cache needlessly > hot is getting through at all. On my lightly loaded desktop: > >  $ sudo lsof | wc -l >  599551 > >  $ sudo lsof | grep "/dev/dri/" | wc -l >  1965 > > It's going to look up ~600k pointless dentries in every iteration. Just > to find a handful of DRM ones. Hard to say if that is better or worse > than just parsing fdinfo text for all files. Will see. CPU usage looks passable under a production kernel (non-debug). Once a second refresh period, on a not really that loaded system (115 running processes, 3096 open file descriptors as reported by lsof, none of which are DRM), results in a system call heavy load: real 0m55.348s user 0m0.100s sys 0m0.319s Once per second loop is essentially along the lines of: for each pid in /proc/: for each fd in /proc//fdinfo: if fstatat(fd) is drm major: read fdinfo text in one sweep and parse it I'll post the quick intel_gpu_top patch for reference but string parsing in C leaves a few things to be desired there. Regards, Tvrtko