Quoting Ho, Kenny (2018-11-27 17:41:17)

On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen [off-list ref] wrote:

quoted

I think a more abstract property "% of GPU (processing power)" might
be a more universal approach. One can then implement that through
subdividing the resources or timeslicing them, depending on the GPU
topology.

Leasing 1/8th, 1/4th or 1/2 of the GPU would probably be the most
applicable to cloud provider usecases, too. At least that's what I
see done for the CPUs today.

I think there are opportunities to slice the gpu in more than one way (similar to the way it is done for cpu.)  We can potentially frame resources as continuous or discrete.  Percentage definitely fits well for continuous measurements such as time/time slices but I think there are places for discrete units such as core counts as well.

I think the ask in return to the early series from Intal was to agree
on the variables that could be common to all of DRM subsystem.

So we can only choose the lowest common denominator, right?

Any core count out of total core count should translate nicely into a
fraction, so what would be the problem with percentage amounts?

Regards, Joonas

Regards,
Kenny

quoted

That combined with the "GPU memory usable" property should be a good
starting point to start subdividing the GPU resources for multiple
users.

Regards, Joonas

quoted

Your feedback is highly appreciated.

Best Regards,
Harish



From: amd-gfx <redacted> on behalf of Tejun Heo <tj@kernel.org>
Sent: Tuesday, November 20, 2018 5:30 PM
To: Ho, Kenny
Cc: cgroups@vger.kernel.org; intel-gfx@lists.freedesktop.org; y2kenny@gmail.com; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices


Hello,

On Tue, Nov 20, 2018 at 10:21:14PM +0000, Ho, Kenny wrote:

quoted

By this reply, are you suggesting that vendor specific resources
will never be acceptable to be managed under cgroup?  Let say a user

I wouldn't say never but whatever which gets included as a cgroup
controller should have clearly defined resource abstractions and the
control schemes around them including support for delegation.  AFAICS,
gpu side still seems to have a long way to go (and it's not clear
whether that's somewhere it will or needs to end up).

quoted

want to have similar functionality as what cgroup is offering but to
manage vendor specific resources, what would you suggest as a
solution?  When you say keeping vendor specific resource regulation
inside drm or specific drivers, do you mean we should replicate the
cgroup infrastructure there or do you mean either drm or specific
driver should query existing hierarchy (such as device or perhaps
cpu) for the process organization information?

To put the questions in more concrete terms, let say a user wants to
expose certain part of a gpu to a particular cgroup similar to the
way selective cpu cores are exposed to a cgroup via cpuset, how
should we go about enabling such functionality?

Do what the intel driver or bpf is doing?  It's not difficult to hook
into cgroup for identification purposes.

Thanks.

--
tejun
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


amd-gfx Info Page - freedesktop.org
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx Archives.. Using amd-gfx: To post a message to all the list members, send email to amd-gfx@lists.freedesktop.org. You can subscribe to the list, or change your existing subscription, in the sections below.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel