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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 5E345C636D4 for ; Thu, 2 Feb 2023 14:24:55 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0BB6910E564; Thu, 2 Feb 2023 14:24:54 +0000 (UTC) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id CF51010E4D6; Mon, 23 Jan 2023 15:42:42 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 78F42339C7; Mon, 23 Jan 2023 15:42:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1674488561; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=55apZeYnu6RO07C6lWHKMqZeQ9QD+dZi2oV45IYgqR8=; b=NwZHaPnSdW0sTqWIpW2Ep2zUuQal9AFNwBLp9xUmbUjAfDGelZ/xsCQDuUGJM72HmTIzWD OVGHfd0I8eI2RL5CanevYwNgICrTG+L9yMtGcFVikSQMyfesIE/B6sHkF1jegMTYHs7TtI KIBufBqOPxkvvdIyiJwOXwaUEQXgNhs= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 236FB1357F; Mon, 23 Jan 2023 15:42:41 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Gh6oB/GqzmNMXgAAMHmgww (envelope-from ); Mon, 23 Jan 2023 15:42:41 +0000 Date: Mon, 23 Jan 2023 16:42:39 +0100 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Tvrtko Ursulin Message-ID: <20230123154239.GA24348@blackbody.suse.cz> References: <20230112165609.1083270-1-tvrtko.ursulin@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20230112165609.1083270-1-tvrtko.ursulin@linux.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Mailman-Approved-At: Thu, 02 Feb 2023 14:24:11 +0000 Subject: Re: [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller 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: Rob Clark , Kenny.Ho@amd.com, Dave Airlie , =?iso-8859-1?Q?St=E9phane?= Marchesin , Daniel Vetter , Intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Christian =?iso-8859-1?Q?K=F6nig?= , Zefan Li , Johannes Weiner , Tejun Heo , cgroups@vger.kernel.org, "T . J . Mercier" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Tvrtko. Interesting work. On Thu, Jan 12, 2023 at 04:55:57PM +0000, Tvrtko Ursulin wrote: > Because of the heterogenous hardware and driver DRM capabilities, soft li= mits > are implemented as a loose co-operative (bi-directional) interface betwee= n the > controller and DRM core. IIUC, this periodic scanning, calculating and applying could be partly implemented with userspace utilities. (As you write, these limits are best effort only, so it sounds to me such a total implementation is unnecessary.) I think a better approach would be to avoid the async querying and instead require implementing explicit foo_charge_time(client, dur) API (similar to how other controllers achieve this). Your argument is the heterogenity of devices -- does it mean there are devices/drivers that can't implement such a synchronous charging?=20 > DRM core provides an API to query per process GPU utilization and 2nd API= to > receive notification from the cgroup controller when the group enters or = exits > the over budget condition. The return value of foo_charge_time() would substitute such a notification synchronously. (By extension all clients in an affected cgroup could be notified to achieve some broader actions.) > Individual DRM drivers which implement the interface are expected to act = on this > in the best-effort manner only. There are no guarantees that the soft lim= its > will be respected. Back to original concern -- must all code reside in the kernel when it's essentially advisory resource control? > * DRM core is required to track all DRM clients belonging to processes s= o it > can answer when asked how much GPU time is a process using. > [...] > * Individual drivers need to implement two similar hooks, but which work= for > a single DRM client. Over budget callback and GPU utilisation query. This information is eventually aggregated for each process in a cgroup. (And the action is carried on a single client, not a process.) The per-process tracking seems like an additional indirection. Could be the clients associated directly with DRM cgroup? [1] Regards, Michal [1] I understand the sending a fd of a client is a regular operation, so I'm not sure how cross-cg migrations would have to be handled in any case. --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTrXXag4J0QvXXBmkMkDQmsBEOquQUCY86q5AAKCRAkDQmsBEOq ueEGAQDI5fZQTAIasuzhXqvhso/sSZM6kjJABNN/jGexID1/AgEA7ESyKCV82koM JsjtlGG3kRl/Y0LhTvA4J7akVFgGdQo= =vAYz -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu--