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 BD653C636CC for ; Mon, 20 Feb 2023 16:51:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 38E6A10E153; Mon, 20 Feb 2023 16:51:48 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id D507810E153; Mon, 20 Feb 2023 16:51:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676911906; x=1708447906; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=K7Pn1omNeLpydk+dmmAEc42pEyc9iZcJzBYelGVHnEU=; b=dfDXf31C9wmD/qnj1uE6ZLAJImRMGZ1zXc+TYnse0XtKQWeyC8aU/Jmp SC3mySSxbY7L0nprJ1ZReu9En31Q1GD8Y/11dextwHpMXPmUdMydBEN+C KnfrvY1pRII2zMm3bMf2BUzPEzIIkRibfCmLuTZmB/VNlydbnyNQtpbqq 42c2MISk6uRUbmaxhQMylyDaschUNRVhdowba1TomfovsZQ5TJKKTAKmO g2EWqB5dpjXBLXnG8qaMsO6H4i7iuA8M9JPkxqNizChDa4KEAHC+s6oP/ Pp0WYRuqkUK5hG8GIg3Ocl2jYFHKvnvJD4gw74J6kFRjtwpBXj7uxWv9c Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10627"; a="312813588" X-IronPort-AV: E=Sophos;i="5.97,313,1669104000"; d="scan'208";a="312813588" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2023 08:51:46 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10627"; a="621209827" X-IronPort-AV: E=Sophos;i="5.97,313,1669104000"; d="scan'208";a="621209827" Received: from mochoamo-mobl.ger.corp.intel.com (HELO [10.213.211.126]) ([10.213.211.126]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Feb 2023 08:51:44 -0800 Message-ID: Date: Mon, 20 Feb 2023 16:51:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits Content-Language: en-US From: Tvrtko Ursulin To: Rob Clark References: <20230210130647.580135-1-tvrtko.ursulin@linux.intel.com> <7e059e8c-41c3-b56c-26c8-c0e2230616b1@linux.intel.com> <6832ba1a-c6b0-4631-3b4e-bfcd31d8b59c@linux.intel.com> <43aff648-df2d-4fa2-356c-b74f5e3a92e7@linux.intel.com> Organization: Intel Corporation UK Plc In-Reply-To: <43aff648-df2d-4fa2-356c-b74f5e3a92e7@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Alex Deucher , Rob Clark , Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Rodrigo Vivi Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 20/02/2023 16:44, Tvrtko Ursulin wrote: > > On 20/02/2023 15:52, Rob Clark wrote: >> On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin >> wrote: >>> >>> >>> On 17/02/2023 20:45, Rodrigo Vivi wrote: > > [snip] > >>> Yeah I agree. And as not all media use cases are the same, as are not >>> all compute contexts someone somewhere will need to run a series of >>> workloads for power and performance numbers. Ideally that someone would >>> be the entity for which it makes sense to look at all use cases, from >>> server room to client, 3d, media and compute for both. If we could get >>> the capability to run this in some automated fashion, akin to CI, we >>> would even have a chance to keep making good decisions in the future. >>> >>> Or we do some one off testing for this instance, but we still need a >>> range of workloads and parts to do it properly.. >>> >>>>> I also think the "arms race" scenario isn't really as much of a >>>>> problem as you think.  There aren't _that_ many things using the GPU >>>>> at the same time (compared to # of things using CPU).   And a lot of >>>>> mobile games throttle framerate to avoid draining your battery too >>>>> quickly (after all, if your battery is dead you can't keep buying loot >>>>> boxes or whatever). >>>> >>>> Very good point. >>> >>> On this one I still disagree from the point of view that it does not >>> make it good uapi if we allow everyone to select themselves for priority >>> handling (one flavour or the other). >> >> There is plenty of precedent for userspace giving hints to the kernel >> about scheduling and freq mgmt.  Like schedutil uclamp stuff. >> Although I think that is all based on cgroups. > > I knew about SCHED_DEADLINE and that it requires CAP_SYS_NICE, but I did > not know about uclamp. Quick experiment with uclampset suggests it > indeed does not require elevated privilege. If that is indeed so, it is > good enough for me as a precedent. > > It appears to work using sched_setscheduler so maybe could define > something similar in i915/xe, per context or per client, not sure. > > Maybe it would start as a primitive implementation but the uapi would > not preclude making it smart(er) afterwards. Or passing along to GuC to > do it's thing with it. Hmmm having said that, how would we fix clvk performance using that? We would either need the library to do a new step when creating contexts, or allow external control so outside entity can do it. And then the question is based on what it decides to do it? Is it possible to know which, for instance, Chrome tab will be (or is) using clvk so that tab management code does it? Regards, Tvrtko >> In the fence/syncobj case, I think we need per-wait hints.. because >> for a single process the driver will be doing both housekeeping waits >> and potentially urgent waits.  There may also be some room for some >> cgroup or similar knobs to control things like what max priority an >> app can ask for, and whether or how aggressively the kernel responds >> to the "deadline" hints.  So as far as "arms race", I don't think I'd > > Per wait hints are okay I guess even with "I am important" in their name > if sched_setscheduler allows raising uclamp.min just like that. In which > case cgroup limits to mimick cpu uclamp also make sense. > >> change anything about my "fence deadline" proposal.. but that it might >> just be one piece of the overall puzzle. > > That SCHED_DEADLINE requires CAP_SYS_NICE does not worry you? > > Regards, > > Tvrtko