From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
"Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Zefan Li" <lizefan.x@bytedance.com>,
"Dave Airlie" <airlied@redhat.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Rob Clark" <robdclark@chromium.org>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"T . J . Mercier" <tjmercier@google.com>,
Kenny.Ho@amd.com, "Christian König" <christian.koenig@amd.com>,
"Brian Welty" <brian.welty@intel.com>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>
Subject: Re: [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control
Date: Fri, 27 Jan 2023 15:21:20 +0000 [thread overview]
Message-ID: <63b6853a-f24f-d97b-0fea-6200a004c41f@linux.intel.com> (raw)
In-Reply-To: <20230127141136.GG3527@blackbody.suse.cz>
On 27/01/2023 14:11, Michal Koutný wrote:
> On Fri, Jan 27, 2023 at 01:31:54PM +0000, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>> I think you missed the finish_suspend_scanning() part:
>>
>> if (root_drmcs.suspended_period_us)
>> cancel_delayed_work_sync(&root_drmcs.scan_work);
>>
>> So if scanning was in progress migration will wait until it finishes.
>
> Indeed, I've missed that. Thank you!
>
>> Not claiming I did not miss something because I was totally new with cgroup
>> internals when I started working on this. So it is definitely useful to have
>> more eyes looking.
>
> The custom with (especially v2, especially horizontal) migrations
> is that they're treated leniently to avoid performance costs.
>
> I'm afraid waiting for scan in can_attach() can propagate globally (via
> cgroup_update_dfl_csses() and cgroup_attach_lock()) sometimes.
That something along those lines might be a concern was indeed worrying
me when coming up with the scheme. Good inside knowledge hint, thank
you. I will have a deeper look.
> OTOH, unless I misunderstood, you need to cover explicit (not task but
> resource, when sending client FD around) migration anyway?
Correct. So far that was handled outside the cgroup controller in the
drm layer and any lock dependency propagation was hidden behind RCU.
But that will likely change once I try your suggestion of eliminating
the struct pid based client tracking and so become relevant.
> (I.e. my suggestion would be to mutualy exclude scanning and explicit
> migration but not scanning and task migration in order to avoid possible
> global propagation.)
Thanks, I will look into this all hopefully shortly. Perhaps what you
suggest will come naturally with the removal of struct pid based tracking.
Regards,
Tvrtko
WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: "Rob Clark" <robdclark@chromium.org>,
Kenny.Ho@amd.com, "Dave Airlie" <airlied@redhat.com>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
Intel-gfx@lists.freedesktop.org,
"Brian Welty" <brian.welty@intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
"Zefan Li" <lizefan.x@bytedance.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Tejun Heo" <tj@kernel.org>,
cgroups@vger.kernel.org, "T . J . Mercier" <tjmercier@google.com>
Subject: Re: [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control
Date: Fri, 27 Jan 2023 15:21:20 +0000 [thread overview]
Message-ID: <63b6853a-f24f-d97b-0fea-6200a004c41f@linux.intel.com> (raw)
In-Reply-To: <20230127141136.GG3527@blackbody.suse.cz>
On 27/01/2023 14:11, Michal Koutný wrote:
> On Fri, Jan 27, 2023 at 01:31:54PM +0000, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>> I think you missed the finish_suspend_scanning() part:
>>
>> if (root_drmcs.suspended_period_us)
>> cancel_delayed_work_sync(&root_drmcs.scan_work);
>>
>> So if scanning was in progress migration will wait until it finishes.
>
> Indeed, I've missed that. Thank you!
>
>> Not claiming I did not miss something because I was totally new with cgroup
>> internals when I started working on this. So it is definitely useful to have
>> more eyes looking.
>
> The custom with (especially v2, especially horizontal) migrations
> is that they're treated leniently to avoid performance costs.
>
> I'm afraid waiting for scan in can_attach() can propagate globally (via
> cgroup_update_dfl_csses() and cgroup_attach_lock()) sometimes.
That something along those lines might be a concern was indeed worrying
me when coming up with the scheme. Good inside knowledge hint, thank
you. I will have a deeper look.
> OTOH, unless I misunderstood, you need to cover explicit (not task but
> resource, when sending client FD around) migration anyway?
Correct. So far that was handled outside the cgroup controller in the
drm layer and any lock dependency propagation was hidden behind RCU.
But that will likely change once I try your suggestion of eliminating
the struct pid based client tracking and so become relevant.
> (I.e. my suggestion would be to mutualy exclude scanning and explicit
> migration but not scanning and task migration in order to avoid possible
> global propagation.)
Thanks, I will look into this all hopefully shortly. Perhaps what you
suggest will come naturally with the removal of struct pid based tracking.
Regards,
Tvrtko
WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: "Rob Clark" <robdclark@chromium.org>,
Kenny.Ho@amd.com, "Dave Airlie" <airlied@redhat.com>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
Intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>,
"Zefan Li" <lizefan.x@bytedance.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Tejun Heo" <tj@kernel.org>,
cgroups@vger.kernel.org, "T . J . Mercier" <tjmercier@google.com>
Subject: Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control
Date: Fri, 27 Jan 2023 15:21:20 +0000 [thread overview]
Message-ID: <63b6853a-f24f-d97b-0fea-6200a004c41f@linux.intel.com> (raw)
In-Reply-To: <20230127141136.GG3527@blackbody.suse.cz>
On 27/01/2023 14:11, Michal Koutný wrote:
> On Fri, Jan 27, 2023 at 01:31:54PM +0000, Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> wrote:
>> I think you missed the finish_suspend_scanning() part:
>>
>> if (root_drmcs.suspended_period_us)
>> cancel_delayed_work_sync(&root_drmcs.scan_work);
>>
>> So if scanning was in progress migration will wait until it finishes.
>
> Indeed, I've missed that. Thank you!
>
>> Not claiming I did not miss something because I was totally new with cgroup
>> internals when I started working on this. So it is definitely useful to have
>> more eyes looking.
>
> The custom with (especially v2, especially horizontal) migrations
> is that they're treated leniently to avoid performance costs.
>
> I'm afraid waiting for scan in can_attach() can propagate globally (via
> cgroup_update_dfl_csses() and cgroup_attach_lock()) sometimes.
That something along those lines might be a concern was indeed worrying
me when coming up with the scheme. Good inside knowledge hint, thank
you. I will have a deeper look.
> OTOH, unless I misunderstood, you need to cover explicit (not task but
> resource, when sending client FD around) migration anyway?
Correct. So far that was handled outside the cgroup controller in the
drm layer and any lock dependency propagation was hidden behind RCU.
But that will likely change once I try your suggestion of eliminating
the struct pid based client tracking and so become relevant.
> (I.e. my suggestion would be to mutualy exclude scanning and explicit
> migration but not scanning and task migration in order to avoid possible
> global propagation.)
Thanks, I will look into this all hopefully shortly. Perhaps what you
suggest will come naturally with the removal of struct pid based tracking.
Regards,
Tvrtko
WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: "Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org>
Cc: Intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Tejun Heo" <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Johannes Weiner"
<hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
"Zefan Li" <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
"Dave Airlie" <airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"Daniel Vetter" <daniel.vetter-/w4YWyX8dFk@public.gmane.org>,
"Rob Clark" <robdclark-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"Stéphane Marchesin"
<marcheu-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"T . J . Mercier"
<tjmercier-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Kenny.Ho-5C7GfCeVMHo@public.gmane.org,
"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>,
"Brian Welty"
<brian.welty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Tvrtko Ursulin"
<tvrtko.ursulin-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control
Date: Fri, 27 Jan 2023 15:21:20 +0000 [thread overview]
Message-ID: <63b6853a-f24f-d97b-0fea-6200a004c41f@linux.intel.com> (raw)
In-Reply-To: <20230127141136.GG3527-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
On 27/01/2023 14:11, Michal Koutný wrote:
> On Fri, Jan 27, 2023 at 01:31:54PM +0000, Tvrtko Ursulin <tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>> I think you missed the finish_suspend_scanning() part:
>>
>> if (root_drmcs.suspended_period_us)
>> cancel_delayed_work_sync(&root_drmcs.scan_work);
>>
>> So if scanning was in progress migration will wait until it finishes.
>
> Indeed, I've missed that. Thank you!
>
>> Not claiming I did not miss something because I was totally new with cgroup
>> internals when I started working on this. So it is definitely useful to have
>> more eyes looking.
>
> The custom with (especially v2, especially horizontal) migrations
> is that they're treated leniently to avoid performance costs.
>
> I'm afraid waiting for scan in can_attach() can propagate globally (via
> cgroup_update_dfl_csses() and cgroup_attach_lock()) sometimes.
That something along those lines might be a concern was indeed worrying
me when coming up with the scheme. Good inside knowledge hint, thank
you. I will have a deeper look.
> OTOH, unless I misunderstood, you need to cover explicit (not task but
> resource, when sending client FD around) migration anyway?
Correct. So far that was handled outside the cgroup controller in the
drm layer and any lock dependency propagation was hidden behind RCU.
But that will likely change once I try your suggestion of eliminating
the struct pid based client tracking and so become relevant.
> (I.e. my suggestion would be to mutualy exclude scanning and explicit
> migration but not scanning and task migration in order to avoid possible
> global propagation.)
Thanks, I will look into this all hopefully shortly. Perhaps what you
suggest will come naturally with the removal of struct pid based tracking.
Regards,
Tvrtko
next prev parent reply other threads:[~2023-01-27 15:21 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-12 16:55 [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller Tvrtko Ursulin
2023-01-12 16:55 ` Tvrtko Ursulin
2023-01-12 16:55 ` Tvrtko Ursulin
2023-01-12 16:55 ` Tvrtko Ursulin
2023-01-12 16:55 ` [RFC 01/12] drm: Track clients by tgid and not tid Tvrtko Ursulin
2023-01-12 16:55 ` Tvrtko Ursulin
2023-01-12 16:55 ` Tvrtko Ursulin
2023-01-12 16:55 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:55 ` [RFC 02/12] drm: Update file owner during use Tvrtko Ursulin
2023-01-12 16:55 ` Tvrtko Ursulin
2023-01-12 16:55 ` Tvrtko Ursulin
2023-01-12 16:55 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 03/12] cgroup: Add the DRM cgroup controller Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 04/12] drm/cgroup: Track clients per owning process Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-17 16:03 ` Stanislaw Gruszka
2023-01-17 16:03 ` Stanislaw Gruszka
2023-01-17 16:03 ` [Intel-gfx] " Stanislaw Gruszka
2023-01-17 16:03 ` Stanislaw Gruszka
2023-01-17 16:25 ` Tvrtko Ursulin
2023-01-17 16:25 ` Tvrtko Ursulin
2023-01-17 16:25 ` Tvrtko Ursulin
2023-01-17 16:25 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 05/12] drm/cgroup: Allow safe external access to file_priv Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 06/12] drm/cgroup: Add ability to query drm cgroup GPU time Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 07/12] drm/cgroup: Add over budget signalling callback Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 08/12] drm/cgroup: Only track clients which are providing drm_cgroup_ops Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 09/12] cgroup/drm: Client exit hook Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-14 21:20 ` kernel test robot
2023-01-27 13:01 ` Michal Koutný
2023-01-27 13:01 ` Michal Koutný
2023-01-27 13:01 ` [Intel-gfx] " Michal Koutný
2023-01-27 13:01 ` Michal Koutný
2023-01-27 13:31 ` Tvrtko Ursulin
2023-01-27 13:31 ` Tvrtko Ursulin
2023-01-27 13:31 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-27 13:31 ` Tvrtko Ursulin
2023-01-27 14:11 ` Michal Koutný
2023-01-27 14:11 ` [Intel-gfx] " Michal Koutný
2023-01-27 14:11 ` Michal Koutný
2023-01-27 15:21 ` Tvrtko Ursulin [this message]
2023-01-27 15:21 ` Tvrtko Ursulin
2023-01-27 15:21 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-27 15:21 ` Tvrtko Ursulin
2023-01-28 1:11 ` Tejun Heo
2023-01-28 1:11 ` Tejun Heo
2023-01-28 1:11 ` [Intel-gfx] " Tejun Heo
2023-01-28 1:11 ` Tejun Heo
2023-02-02 14:26 ` Tvrtko Ursulin
2023-02-02 14:26 ` Tvrtko Ursulin
2023-02-02 14:26 ` [Intel-gfx] " Tvrtko Ursulin
2023-02-02 14:26 ` Tvrtko Ursulin
2023-02-02 20:00 ` Tejun Heo
2023-02-02 20:00 ` Tejun Heo
2023-02-02 20:00 ` [Intel-gfx] " Tejun Heo
2023-02-02 20:00 ` Tejun Heo
2023-01-12 16:56 ` [RFC 11/12] drm/i915: Wire up with drm controller GPU time query Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 16:56 ` [RFC 12/12] drm/i915: Implement cgroup controller over budget throttling Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` Tvrtko Ursulin
2023-01-12 16:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-12 17:40 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DRM scheduling cgroup controller (rev3) Patchwork
2023-01-12 18:09 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-01-13 6:52 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-01-23 15:42 ` [RFC v3 00/12] DRM scheduling cgroup controller Michal Koutný
2023-01-23 15:42 ` Michal Koutný
2023-01-23 15:42 ` [Intel-gfx] " Michal Koutný
2023-01-23 15:42 ` Michal Koutný
2023-01-25 18:11 ` Tvrtko Ursulin
2023-01-25 18:11 ` Tvrtko Ursulin
2023-01-25 18:11 ` Tvrtko Ursulin
2023-01-25 18:11 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-26 13:00 ` Michal Koutný
2023-01-26 13:00 ` Michal Koutný
2023-01-26 13:00 ` [Intel-gfx] " Michal Koutný
2023-01-26 13:00 ` Michal Koutný
2023-01-26 17:04 ` Tejun Heo
2023-01-26 17:04 ` Tejun Heo
2023-01-26 17:04 ` [Intel-gfx] " Tejun Heo
2023-01-26 17:04 ` Tejun Heo
2023-01-26 17:57 ` Tvrtko Ursulin
2023-01-26 17:57 ` Tvrtko Ursulin
2023-01-26 17:57 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-26 17:57 ` Tvrtko Ursulin
2023-01-26 18:14 ` Tvrtko Ursulin
2023-01-26 18:14 ` Tvrtko Ursulin
2023-01-26 18:14 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-26 18:14 ` Tvrtko Ursulin
2023-01-27 10:04 ` Michal Koutný
2023-01-27 10:04 ` Michal Koutný
2023-01-27 10:04 ` [Intel-gfx] " Michal Koutný
2023-01-27 10:04 ` Michal Koutný
2023-01-27 11:40 ` Tvrtko Ursulin
2023-01-27 11:40 ` Tvrtko Ursulin
2023-01-27 11:40 ` Tvrtko Ursulin
2023-01-27 11:40 ` [Intel-gfx] " Tvrtko Ursulin
2023-01-27 13:00 ` Michal Koutný
2023-01-27 13:00 ` [Intel-gfx] " Michal Koutný
2023-01-27 13:00 ` Michal Koutný
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63b6853a-f24f-d97b-0fea-6200a004c41f@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=Kenny.Ho@amd.com \
--cc=airlied@redhat.com \
--cc=brian.welty@intel.com \
--cc=cgroups@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=marcheu@chromium.org \
--cc=mkoutny@suse.com \
--cc=robdclark@chromium.org \
--cc=tj@kernel.org \
--cc=tjmercier@google.com \
--cc=tvrtko.ursulin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.