Received: by 2002:a05:6358:701b:b0:131:369:b2a3 with SMTP id 27csp4530467rwo; Tue, 25 Jul 2023 07:25:19 -0700 (PDT) X-Google-Smtp-Source: APBJJlHIEPnvmyRtREM8idJK042ftOX6db+ULTg4QIs/hkYWkipYQuaLqQ6xG0VYJQu5Zd99VNhA X-Received: by 2002:a05:6358:910:b0:137:d0bb:5c31 with SMTP id r16-20020a056358091000b00137d0bb5c31mr10090069rwi.7.1690295119345; Tue, 25 Jul 2023 07:25:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690295119; cv=none; d=google.com; s=arc-20160816; b=o8oilbMnsSM8zRT6KnZfMLNZBv87XeoMU+Wua3omv32BBoerPtrvsyck1HW5RvJq5T 103qYb6CiRT96zlXfDMddDAbd2/yOzrHgUJS+mCcZZ/2dL4uVK/VMaHeHQQvnqDkpo3c Zdw8qLXdjVoSaSGcdueOjWSogkwVHkTwmYfsweu3aQ80VyAy4fbFI1GvEnW+KHrxbtEh 7ycfVLfiljVUlO4LnbkkDeDIu/DOzPqWTHvX5br3lVlfd9bOzm9/Wsa2GIxxUi/ItsZl M2ooONh1tP3YGU5elVIA8+V3eCVYJCaFwx7XjiTLbM91B8Kw9KGcr12XgIN0WQN/auak fPPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :organization:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:dkim-signature; bh=iPA316BAyV5hE0YjAwgzT4WpgY4Jl5PBIbgpIlqjOqk=; fh=9DGt3kI8lqUID8+3h1/7OaJ0UFSZLkv9Vvjluqg6wdc=; b=nXfQXt6Z8CPACytH01LCHzRM2IVl/n2s3QOuTv/ejyuPgbGfGZLSjZT4ANiE41WRIN 7lssSTsROb5mJF/sP5NdNDe+yJRmlINm8vbBnBpUhv37/g0Fp/y8frlphmERWwQSyDUo x/9zRBNKhd5aZlee1adeEaS/QQxEmRFf9qRLUH3UXBdt1BvPS8g08GuGRNxz8DZknzK1 3J1VzffYZ2mUtVVvo/qFOCysvIdx41ZmX3fdfDMjoj/ZYU+9ZlFsf0JHYiIHbQNjT//j ulWKsjlYldbmfqOr/o8YL8Mi2hLUquF0v9id5odvoup2vpCxbhtlaoUwcINUqaPgRne7 ZwXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Kw2roxen; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bv69-20020a632e48000000b0055bbc74626esi11845131pgb.217.2023.07.25.07.25.06; Tue, 25 Jul 2023 07:25:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Kw2roxen; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232388AbjGYOJC (ORCPT + 99 others); Tue, 25 Jul 2023 10:09:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230154AbjGYOIv (ORCPT ); Tue, 25 Jul 2023 10:08:51 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65C9D1FF0; Tue, 25 Jul 2023 07:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690294128; x=1721830128; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Knqc8R0mT6fenbyn7oqDjc0TJDtO4aGF9VcaDoL2Pq8=; b=Kw2roxenD2KMHCw+N03NZrl6duCrXAUItgXOWDVwYO/z1lbyGnVIkdEc H5VGnLpERcRnVkKTz+EgZPlOTfkzgzFAJ7Zb1o6RaA+IiEbAHlOlOhLER U2Y2iYyOU5+DlZ/tNC+Uka5gn4UnOe65t3PQhSrlI2+qH0M5dsL/iic8t qor04Kv5O2ag5va8qzmyAme8R7rwarQ+pyLkungroq4VoubRcwtG0CAZV KDIrX60BVyZ7ZajsKe6dcwsskwcGRf07leoX6bDainHGJc3w4HhKhhNvE sx0nI21Quo3Q9xAtBBJy40qNPYYURl2onAMuftIR8JfFKZRdRXaThk0t6 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10782"; a="347340882" X-IronPort-AV: E=Sophos;i="6.01,230,1684825200"; d="scan'208";a="347340882" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2023 07:08:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10782"; a="816266454" X-IronPort-AV: E=Sophos;i="6.01,230,1684825200"; d="scan'208";a="816266454" Received: from grdarcy-mobl1.ger.corp.intel.com (HELO [10.213.228.4]) ([10.213.228.4]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2023 07:08:42 -0700 Message-ID: <3b96cada-3433-139c-3180-1f050f0f80f3@linux.intel.com> Date: Tue, 25 Jul 2023 15:08:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 15/17] cgroup/drm: Expose GPU utilisation Content-Language: en-US To: Tejun Heo Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Johannes Weiner , Zefan Li , Dave Airlie , Daniel Vetter , Rob Clark , =?UTF-8?Q?St=c3=a9phane_Marchesin?= , "T . J . Mercier" , Kenny.Ho@amd.com, =?UTF-8?Q?Christian_K=c3=b6nig?= , Brian Welty , Tvrtko Ursulin , Eero Tamminen References: <20230712114605.519432-1-tvrtko.ursulin@linux.intel.com> <20230712114605.519432-16-tvrtko.ursulin@linux.intel.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HK_RANDOM_ENVFROM,HK_RANDOM_FROM, NICE_REPLY_A,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/07/2023 23:20, Tejun Heo wrote: > On Fri, Jul 21, 2023 at 12:19:32PM -1000, Tejun Heo wrote: >> On Wed, Jul 12, 2023 at 12:46:03PM +0100, Tvrtko Ursulin wrote: >>> + drm.active_us >>> + GPU time used by the group recursively including all child groups. >> >> Maybe instead add drm.stat and have "usage_usec" inside? That'd be more >> consistent with cpu side. Could be, but no strong opinion from my side either way. Perhaps it boils down to what could be put in the file, I mean to decide whether keyed format makes sense or not. > Also, shouldn't this be keyed by the drm device? It could have that too, or it could come later. Fun with GPUs that it not only could be keyed by the device, but also by the type of the GPU engine. (Which are a) vendor specific and b) some aree fully independent, some partially so, and some not at all - so it could get complicated semantics wise really fast.) If for now I'd go with drm.stat/usage_usec containing the total time spent how would you suggest adding per device granularity? Files as documented are either flag or nested, not both at the same time. So something like: usage_usec 100000 card0 usage_usec 50000 card1 usage_usec 50000 Would or would not fly? Have two files along the lines of drm.stat and drm.dev_stat? While on this general topic, you will notice that for memory stats I have _sort of_ nested keyed per device format, for example on integrated Intel GPU: $ cat drm.memory.stat card0 region=system total=12898304 shared=0 active=0 resident=12111872 purgeable=167936 card0 region=stolen-system total=0 shared=0 active=0 resident=0 purgeable=0 If one a discrete Intel GPU two more lines would appear with memory regions of local and local-system. But then on some server class multi-tile GPUs even further regions with more than one device local memory region. And users do want to see this granularity for container use cases at least. Anyway, this may not be compatible with the nested key format as documented in cgroup-v2.rst, although it does not explicitly say. Should I cheat and create key names based on device and memory region name and let userspace parse it? Like: $ cat drm.memory.stat card0.system total=12898304 shared=0 active=0 resident=12111872 purgeable=167936 card0.stolen-system total=0 shared=0 active=0 resident=0 purgeable=0 Regards, Tvrtko