Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Thanks, I will take a look. Regards, Kenny On Wed, Feb 19, 2020 at 1:38 PM Johannes Weiner wrote: > > On Wed, Feb 19, 2020 at 11:28:48AM -0500, Kenny Ho wrote: > > On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner wrote: > > > > > > Yes, I'd go with absolute units when it comes to memory, because it's > > > not a renewable resource like CPU and IO, and so we do have cliff > > > behavior around the edge where you transition from ok to not-enough. > > > > > > memory.low is a bit in flux right now, so if anything is unclear > > > around its semantics, please feel free to reach out. > > > > I am not familiar with the discussion, would you point me to a > > relevant thread please? > > Here is a cleanup patch, not yet merged, that documents the exact > semantics and behavioral considerations: > > https://lore.kernel.org/linux-mm/20191213192158.188939-3-han...@cmpxchg.org/ > > But the high-level idea is this: you assign each cgroup or cgroup > subtree a chunk of the resource that it's guaranteed to be able to > consume. It *can* consume beyond that threshold if available, but that > overage may get reclaimed again if somebody else needs it instead. > > This allows you to do a ballpark distribution of the resource between > different workloads, while the kernel retains the ability to optimize > allocation of spare resources - because in practice, workload demand > varies over time, workloads disappear and new ones start up etc. > > > In addition, is there some kind of order of preference for > > implementing low vs high vs max? > > If you implement only one allocation model, the preference would be on > memory.low. Limits are rigid and per definition waste resources, so in > practice we're moving away from them. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Wed, Feb 19, 2020 at 11:28:48AM -0500, Kenny Ho wrote: > On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner wrote: > > > > Yes, I'd go with absolute units when it comes to memory, because it's > > not a renewable resource like CPU and IO, and so we do have cliff > > behavior around the edge where you transition from ok to not-enough. > > > > memory.low is a bit in flux right now, so if anything is unclear > > around its semantics, please feel free to reach out. > > I am not familiar with the discussion, would you point me to a > relevant thread please? Here is a cleanup patch, not yet merged, that documents the exact semantics and behavioral considerations: https://lore.kernel.org/linux-mm/20191213192158.188939-3-han...@cmpxchg.org/ But the high-level idea is this: you assign each cgroup or cgroup subtree a chunk of the resource that it's guaranteed to be able to consume. It *can* consume beyond that threshold if available, but that overage may get reclaimed again if somebody else needs it instead. This allows you to do a ballpark distribution of the resource between different workloads, while the kernel retains the ability to optimize allocation of spare resources - because in practice, workload demand varies over time, workloads disappear and new ones start up etc. > In addition, is there some kind of order of preference for > implementing low vs high vs max? If you implement only one allocation model, the preference would be on memory.low. Limits are rigid and per definition waste resources, so in practice we're moving away from them. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner wrote: > > Yes, I'd go with absolute units when it comes to memory, because it's > not a renewable resource like CPU and IO, and so we do have cliff > behavior around the edge where you transition from ok to not-enough. > > memory.low is a bit in flux right now, so if anything is unclear > around its semantics, please feel free to reach out. I am not familiar with the discussion, would you point me to a relevant thread please? In addition, is there some kind of order of preference for implementing low vs high vs max? Regards, Kenny ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 03:28:40PM -0500, Kenny Ho wrote: > On Fri, Feb 14, 2020 at 2:17 PM Tejun Heo wrote: > > Also, a rather trivial high level question. Is drm a good controller > > name given that other controller names are like cpu, memory, io? > > There was a discussion about naming early in the RFC (I believe > RFCv2), the consensuses then was to use drmcg to align with the drm > subsystem. I have no problem renaming it to gpucg or something > similar if that is the last thing that's blocking acceptance. For > now, I would like to get some clarity on the implementation before > having more code churn. As far as precedence goes, we named the other controllers after the resources they control rather than the subsystem: cpu instead of scheduler, memory instead of mm, io instead of block layer etc. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 02:17:54PM -0500, Tejun Heo wrote: > Hello, Kenny, Daniel. > > (cc'ing Johannes) > > On Fri, Feb 14, 2020 at 01:51:32PM -0500, Kenny Ho wrote: > > On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter wrote: > > > > > > I think guidance from Tejun in previos discussions was pretty clear that > > > he expects cgroups to be both a) standardized and c) sufficient clear > > > meaning that end-users have a clear understanding of what happens when > > > they change the resource allocation. > > > > > > I'm not sure lgpu here, at least as specified, passes either. > > > > I disagree (at least on the characterization of the feedback > > provided.) I believe this series satisfied the sprite of Tejun's > > guidance so far (the weight knob for lgpu, for example, was > > specifically implemented base on his input.) But, I will let Tejun > > speak for himself after he considered the implementation in detail. > > I have to agree with Daniel here. My apologies if I weren't clear > enough. Here's one interface I can think of: > > * compute weight: The same format as io.weight. Proportional control >of gpu compute. > > * memory low: Please see how the system memory.low behaves. For gpus, >it'll need per-device entries. > > Note that for both, there one number to configure and conceptually > it's pretty clear to everybody what that number means, which is not to > say that it's clear to implement but it's much better to deal with > that on this side of the interface than the other. > > cc'ing Johannes. Do you have anything on mind regarding how gpu memory > configuration should look like? e.g. should it go w/ weights rather > than absoulte units (I don't think so given that it'll most likely > need limits at some point too but still and there are benefits from > staying consistent with system memory). Yes, I'd go with absolute units when it comes to memory, because it's not a renewable resource like CPU and IO, and so we do have cliff behavior around the edge where you transition from ok to not-enough. memory.low is a bit in flux right now, so if anything is unclear around its semantics, please feel free to reach out. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 03:28:40PM -0500, Kenny Ho wrote: > Can you elaborate, per your understanding, how the lgpu weight > attribute differ from the io.weight you suggested? Is it merely a Oh, it's the non-weight part which is problematic. > formatting/naming issue or is it the implementation details that you > find troubling? From my perspective, the weight attribute implements > as you suggested back in RFCv4 (proportional control on top of a unit > - either physical or time unit.) > > Perhaps more explicit questions would help me understand what you > mean. If I remove the 'list' and 'count' attributes leaving just > weight, is that satisfactory? Are you saying the idea of affinity or At least from interface pov, yes, although I think it should be clear what the weight controls. > named-resource is banned from cgroup entirely (even though it exists > in the form of cpuset already and users are interested in having such > options [i.e. userspace OpenCL] when needed?) > > To be clear, I am not saying no proportional control. I am saying > give the user the options, which is what has been implemented. We can get there if we *really* have to but not from the get-go but I'd rather avoid affinities if at all possible. Thanks. -- tejun ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Hi Tejun, On Fri, Feb 14, 2020 at 2:17 PM Tejun Heo wrote: > > I have to agree with Daniel here. My apologies if I weren't clear > enough. Here's one interface I can think of: > > * compute weight: The same format as io.weight. Proportional control >of gpu compute. > > * memory low: Please see how the system memory.low behaves. For gpus, >it'll need per-device entries. > > Note that for both, there one number to configure and conceptually > it's pretty clear to everybody what that number means, which is not to > say that it's clear to implement but it's much better to deal with > that on this side of the interface than the other. Can you elaborate, per your understanding, how the lgpu weight attribute differ from the io.weight you suggested? Is it merely a formatting/naming issue or is it the implementation details that you find troubling? From my perspective, the weight attribute implements as you suggested back in RFCv4 (proportional control on top of a unit - either physical or time unit.) Perhaps more explicit questions would help me understand what you mean. If I remove the 'list' and 'count' attributes leaving just weight, is that satisfactory? Are you saying the idea of affinity or named-resource is banned from cgroup entirely (even though it exists in the form of cpuset already and users are interested in having such options [i.e. userspace OpenCL] when needed?) To be clear, I am not saying no proportional control. I am saying give the user the options, which is what has been implemented. > cc'ing Johannes. Do you have anything on mind regarding how gpu memory > configuration should look like? e.g. should it go w/ weights rather > than absoulte units (I don't think so given that it'll most likely > need limits at some point too but still and there are benefits from > staying consistent with system memory). > > Also, a rather trivial high level question. Is drm a good controller > name given that other controller names are like cpu, memory, io? There was a discussion about naming early in the RFC (I believe RFCv2), the consensuses then was to use drmcg to align with the drm subsystem. I have no problem renaming it to gpucg or something similar if that is the last thing that's blocking acceptance. For now, I would like to get some clarity on the implementation before having more code churn. Regards, Kenny > Thanks. > > -- > tejun ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Hello, Kenny, Daniel. (cc'ing Johannes) On Fri, Feb 14, 2020 at 01:51:32PM -0500, Kenny Ho wrote: > On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter wrote: > > > > I think guidance from Tejun in previos discussions was pretty clear that > > he expects cgroups to be both a) standardized and c) sufficient clear > > meaning that end-users have a clear understanding of what happens when > > they change the resource allocation. > > > > I'm not sure lgpu here, at least as specified, passes either. > > I disagree (at least on the characterization of the feedback > provided.) I believe this series satisfied the sprite of Tejun's > guidance so far (the weight knob for lgpu, for example, was > specifically implemented base on his input.) But, I will let Tejun > speak for himself after he considered the implementation in detail. I have to agree with Daniel here. My apologies if I weren't clear enough. Here's one interface I can think of: * compute weight: The same format as io.weight. Proportional control of gpu compute. * memory low: Please see how the system memory.low behaves. For gpus, it'll need per-device entries. Note that for both, there one number to configure and conceptually it's pretty clear to everybody what that number means, which is not to say that it's clear to implement but it's much better to deal with that on this side of the interface than the other. cc'ing Johannes. Do you have anything on mind regarding how gpu memory configuration should look like? e.g. should it go w/ weights rather than absoulte units (I don't think so given that it'll most likely need limits at some point too but still and there are benefits from staying consistent with system memory). Also, a rather trivial high level question. Is drm a good controller name given that other controller names are like cpu, memory, io? Thanks. -- tejun ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 1:34 PM Daniel Vetter wrote: > > I think guidance from Tejun in previos discussions was pretty clear that > he expects cgroups to be both a) standardized and c) sufficient clear > meaning that end-users have a clear understanding of what happens when > they change the resource allocation. > > I'm not sure lgpu here, at least as specified, passes either. I disagree (at least on the characterization of the feedback provided.) I believe this series satisfied the sprite of Tejun's guidance so far (the weight knob for lgpu, for example, was specifically implemented base on his input.) But, I will let Tejun speak for himself after he considered the implementation in detail. Regards, Kenny > But I also > don't have much clue, so pulled Jason in - he understands how this all > gets reflected to userspace apis a lot better than me. > -Daniel > > > > > > > If it's carving up compute power, what's actually being carved up? Time? > > > Execution units/waves/threads? Even if that's the case, what advantage > > > does it give to have it in terms of a fixed set of lgpus where each > > > cgroup gets to pick a fixed set. Does affinity matter that much? Why > > > not just say how many waves the GPU supports and that they have to be > > > allocated in chunks of 16 waves (pulling a number out of thin air) and > > > let the cgroup specify how many waves it wants. > > > > > > Don't get me wrong here. I'm all for the notion of being able to use > > > cgroups to carve up GPU compute resources. However, this sounds to me > > > like the most AMD-specific solution possible. We (Intel) could probably > > > do some sort of carving up as well but we'd likely want to do it with > > > preemption and time-slicing rather than handing out specific EUs. > > > > This has been discussed in the RFC before > > (https://www.spinics.net/lists/cgroups/msg23469.html.) As mentioned > > before, the idea of a compute unit is hardly an AMD specific thing as > > it is in the OpenCL standard and part of the architecture of many > > different vendors. In addition, the interface presented here supports > > Intel's use case. What you described is what I considered as the > > "anonymous resources" view of the lgpu. What you/Intel can do, is to > > register your device to drmcg to have 100 lgpu and users can specify > > simply by count. So if they want to allocate 5% for a cgroup, they > > would set count=5. Per the documentation in this patch: "Some DRM > > devices may only support lgpu as anonymous resources. In such case, > > the significance of the position of the set bits in list will be > > ignored." What Intel does with the user expressed configuration of "5 > > out of 100" is entirely up to Intel (time slice if you like, change to > > specific EUs later if you like, or make it driver configurable to > > support both if you like.) > > > > Regards, > > Kenny > > > > > > > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: > > >> > > >> drm.lgpu > > >> A read-write nested-keyed file which exists on all cgroups. > > >> Each entry is keyed by the DRM device's major:minor. > > >> > > >> lgpu stands for logical GPU, it is an abstraction used to > > >> subdivide a physical DRM device for the purpose of resource > > >> management. This file stores user configuration while the > > >> drm.lgpu.effective reflects the actual allocation after > > >> considering the relationship between the cgroups and their > > >> configurations. > > >> > > >> The lgpu is a discrete quantity that is device specific (i.e. > > >> some DRM devices may have 64 lgpus while others may have 100 > > >> lgpus.) The lgpu is a single quantity that can be allocated > > >> in three different ways denoted by the following nested keys. > > >> > > >> = == > > >> weightAllocate by proportion in relationship with > > >> active sibling cgroups > > >> count Allocate by amount statically, treat lgpu as > > >> anonymous resources > > >> list Allocate statically, treat lgpu as named > > >> resource > > >> = == > > >> > > >> For example: > > >> 226:0 weight=100 count=256 list=0-255 > > >> 226:1 weight=100 count=4 list=0,2,4,6 > > >> 226:2 weight=100 count=32 list=32-63 > > >> 226:3 weight=100 count=0 list= > > >> 226:4 weight=500 count=0 list= > > >> > > >> lgpu is represented by a bitmap and uses the bitmap_parselist > > >> kernel function so the list key input format is a > > >> comma-separated list of decimal numbers and ranges. > > >> > > >> Consecutively set bits are shown as two hyphen-separated decimal > > >> numbers, the smallest and largest bit numbers set in the range. > > >> Optionally
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 12:08:35PM -0500, Kenny Ho wrote: > Hi Jason, > > Thanks for the review. > > On Fri, Feb 14, 2020 at 11:44 AM Jason Ekstrand wrote: > > > > Pardon my ignorance but I'm a bit confused by this. What is a "logical > > GPU"? What are we subdividing? Are we carving up memory? Compute power? > > Both? > > The intention is compute but it is up to the individual drm driver to decide. I think guidance from Tejun in previos discussions was pretty clear that he expects cgroups to be both a) standardized and c) sufficient clear meaning that end-users have a clear understanding of what happens when they change the resource allocation. I'm not sure lgpu here, at least as specified, passes either. But I also don't have much clue, so pulled Jason in - he understands how this all gets reflected to userspace apis a lot better than me. -Daniel > > > If it's carving up compute power, what's actually being carved up? Time? > > Execution units/waves/threads? Even if that's the case, what advantage > > does it give to have it in terms of a fixed set of lgpus where each cgroup > > gets to pick a fixed set. Does affinity matter that much? Why not just > > say how many waves the GPU supports and that they have to be allocated in > > chunks of 16 waves (pulling a number out of thin air) and let the cgroup > > specify how many waves it wants. > > > > Don't get me wrong here. I'm all for the notion of being able to use > > cgroups to carve up GPU compute resources. However, this sounds to me like > > the most AMD-specific solution possible. We (Intel) could probably do some > > sort of carving up as well but we'd likely want to do it with preemption > > and time-slicing rather than handing out specific EUs. > > This has been discussed in the RFC before > (https://www.spinics.net/lists/cgroups/msg23469.html.) As mentioned > before, the idea of a compute unit is hardly an AMD specific thing as > it is in the OpenCL standard and part of the architecture of many > different vendors. In addition, the interface presented here supports > Intel's use case. What you described is what I considered as the > "anonymous resources" view of the lgpu. What you/Intel can do, is to > register your device to drmcg to have 100 lgpu and users can specify > simply by count. So if they want to allocate 5% for a cgroup, they > would set count=5. Per the documentation in this patch: "Some DRM > devices may only support lgpu as anonymous resources. In such case, > the significance of the position of the set bits in list will be > ignored." What Intel does with the user expressed configuration of "5 > out of 100" is entirely up to Intel (time slice if you like, change to > specific EUs later if you like, or make it driver configurable to > support both if you like.) > > Regards, > Kenny > > > > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: > >> > >> drm.lgpu > >> A read-write nested-keyed file which exists on all cgroups. > >> Each entry is keyed by the DRM device's major:minor. > >> > >> lgpu stands for logical GPU, it is an abstraction used to > >> subdivide a physical DRM device for the purpose of resource > >> management. This file stores user configuration while the > >> drm.lgpu.effective reflects the actual allocation after > >> considering the relationship between the cgroups and their > >> configurations. > >> > >> The lgpu is a discrete quantity that is device specific (i.e. > >> some DRM devices may have 64 lgpus while others may have 100 > >> lgpus.) The lgpu is a single quantity that can be allocated > >> in three different ways denoted by the following nested keys. > >> > >> = == > >> weightAllocate by proportion in relationship with > >> active sibling cgroups > >> count Allocate by amount statically, treat lgpu as > >> anonymous resources > >> list Allocate statically, treat lgpu as named > >> resource > >> = == > >> > >> For example: > >> 226:0 weight=100 count=256 list=0-255 > >> 226:1 weight=100 count=4 list=0,2,4,6 > >> 226:2 weight=100 count=32 list=32-63 > >> 226:3 weight=100 count=0 list= > >> 226:4 weight=500 count=0 list= > >> > >> lgpu is represented by a bitmap and uses the bitmap_parselist > >> kernel function so the list key input format is a > >> comma-separated list of decimal numbers and ranges. > >> > >> Consecutively set bits are shown as two hyphen-separated decimal > >> numbers, the smallest and largest bit numbers set in the range. > >> Optionally each range can be postfixed to denote that only parts > >> of it should be set. The range will divided to groups of > >> specific size. > >>
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 11:08 AM Kenny Ho wrote: > > Hi Jason, > > Thanks for the review. > > On Fri, Feb 14, 2020 at 11:44 AM Jason Ekstrand wrote: > > > > Pardon my ignorance but I'm a bit confused by this. What is a "logical > > GPU"? What are we subdividing? Are we carving up memory? Compute power? > > Both? > > The intention is compute but it is up to the individual drm driver to decide. > > > If it's carving up compute power, what's actually being carved up? Time? > > Execution units/waves/threads? Even if that's the case, what advantage > > does it give to have it in terms of a fixed set of lgpus where each cgroup > > gets to pick a fixed set. Does affinity matter that much? Why not just > > say how many waves the GPU supports and that they have to be allocated in > > chunks of 16 waves (pulling a number out of thin air) and let the cgroup > > specify how many waves it wants. > > > > Don't get me wrong here. I'm all for the notion of being able to use > > cgroups to carve up GPU compute resources. However, this sounds to me like > > the most AMD-specific solution possible. We (Intel) could probably do some > > sort of carving up as well but we'd likely want to do it with preemption > > and time-slicing rather than handing out specific EUs. > > This has been discussed in the RFC before > (https://www.spinics.net/lists/cgroups/msg23469.html.) As mentioned > before, the idea of a compute unit is hardly an AMD specific thing as > it is in the OpenCL standard and part of the architecture of many > different vendors. In addition, the interface presented here supports > Intel's use case. What you described is what I considered as the > "anonymous resources" view of the lgpu. What you/Intel can do, is to > register your device to drmcg to have 100 lgpu and users can specify > simply by count. So if they want to allocate 5% for a cgroup, they > would set count=5. Per the documentation in this patch: "Some DRM > devices may only support lgpu as anonymous resources. In such case, > the significance of the position of the set bits in list will be > ignored." What Intel does with the user expressed configuration of "5 > out of 100" is entirely up to Intel (time slice if you like, change to > specific EUs later if you like, or make it driver configurable to > support both if you like.) Sure, there's an OpenCL thing. However, just because there's an OpenCL thing doesn't mean that it's as standardized as it looks. :-( In particular, 1. The OpenCL thing has a query first to ask the driver what kind of carving up of the GPU is allowed 2. When clCreateSubdevices is called, the type of partitioning is specified so they can specifically ask for devices grouped by shared L2 cache, for instance. 3. Just because the API exists and everyone implements it doesn't mean that everyone implements it usefully. From my reading of the spec, it looks like the API is very much designed towards a CPU implementation of OpenCL. The Intel OpenCL GPU compute drivers, for instance, implement it as a total no-op and no real sub-dividing is allowed. That said, that doesn't necessarily mean that carving up units of compute power is a bad plan. It's just unclear (as Daniel said on the above referenced chain) what those units mean. Maybe it's ok if they mean nothing or if their meaning is HW-specific? > Regards, > Kenny > > > > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: > >> > >> drm.lgpu > >> A read-write nested-keyed file which exists on all cgroups. > >> Each entry is keyed by the DRM device's major:minor. > >> > >> lgpu stands for logical GPU, it is an abstraction used to > >> subdivide a physical DRM device for the purpose of resource > >> management. This file stores user configuration while the > >> drm.lgpu.effective reflects the actual allocation after > >> considering the relationship between the cgroups and their > >> configurations. > >> > >> The lgpu is a discrete quantity that is device specific (i.e. > >> some DRM devices may have 64 lgpus while others may have 100 > >> lgpus.) The lgpu is a single quantity that can be allocated > >> in three different ways denoted by the following nested keys. > >> > >> = == > >> weightAllocate by proportion in relationship with > >> active sibling cgroups > >> count Allocate by amount statically, treat lgpu as > >> anonymous resources > >> list Allocate statically, treat lgpu as named > >> resource > >> = == > >> > >> For example: > >> 226:0 weight=100 count=256 list=0-255 > >> 226:1 weight=100 count=4 list=0,2,4,6 > >> 226:2 weight=100 count=32 list=32-63 > >> 226:3 weight=100 count=0 list= > >> 226:4 weight=500 count=0
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Hi Jason, Thanks for the review. On Fri, Feb 14, 2020 at 11:44 AM Jason Ekstrand wrote: > > Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? > What are we subdividing? Are we carving up memory? Compute power? Both? The intention is compute but it is up to the individual drm driver to decide. > If it's carving up compute power, what's actually being carved up? Time? > Execution units/waves/threads? Even if that's the case, what advantage does > it give to have it in terms of a fixed set of lgpus where each cgroup gets to > pick a fixed set. Does affinity matter that much? Why not just say how many > waves the GPU supports and that they have to be allocated in chunks of 16 > waves (pulling a number out of thin air) and let the cgroup specify how many > waves it wants. > > Don't get me wrong here. I'm all for the notion of being able to use cgroups > to carve up GPU compute resources. However, this sounds to me like the most > AMD-specific solution possible. We (Intel) could probably do some sort of > carving up as well but we'd likely want to do it with preemption and > time-slicing rather than handing out specific EUs. This has been discussed in the RFC before (https://www.spinics.net/lists/cgroups/msg23469.html.) As mentioned before, the idea of a compute unit is hardly an AMD specific thing as it is in the OpenCL standard and part of the architecture of many different vendors. In addition, the interface presented here supports Intel's use case. What you described is what I considered as the "anonymous resources" view of the lgpu. What you/Intel can do, is to register your device to drmcg to have 100 lgpu and users can specify simply by count. So if they want to allocate 5% for a cgroup, they would set count=5. Per the documentation in this patch: "Some DRM devices may only support lgpu as anonymous resources. In such case, the significance of the position of the set bits in list will be ignored." What Intel does with the user expressed configuration of "5 out of 100" is entirely up to Intel (time slice if you like, change to specific EUs later if you like, or make it driver configurable to support both if you like.) Regards, Kenny > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: >> >> drm.lgpu >> A read-write nested-keyed file which exists on all cgroups. >> Each entry is keyed by the DRM device's major:minor. >> >> lgpu stands for logical GPU, it is an abstraction used to >> subdivide a physical DRM device for the purpose of resource >> management. This file stores user configuration while the >> drm.lgpu.effective reflects the actual allocation after >> considering the relationship between the cgroups and their >> configurations. >> >> The lgpu is a discrete quantity that is device specific (i.e. >> some DRM devices may have 64 lgpus while others may have 100 >> lgpus.) The lgpu is a single quantity that can be allocated >> in three different ways denoted by the following nested keys. >> >> = == >> weightAllocate by proportion in relationship with >> active sibling cgroups >> count Allocate by amount statically, treat lgpu as >> anonymous resources >> list Allocate statically, treat lgpu as named >> resource >> = == >> >> For example: >> 226:0 weight=100 count=256 list=0-255 >> 226:1 weight=100 count=4 list=0,2,4,6 >> 226:2 weight=100 count=32 list=32-63 >> 226:3 weight=100 count=0 list= >> 226:4 weight=500 count=0 list= >> >> lgpu is represented by a bitmap and uses the bitmap_parselist >> kernel function so the list key input format is a >> comma-separated list of decimal numbers and ranges. >> >> Consecutively set bits are shown as two hyphen-separated decimal >> numbers, the smallest and largest bit numbers set in the range. >> Optionally each range can be postfixed to denote that only parts >> of it should be set. The range will divided to groups of >> specific size. >> Syntax: range:used_size/group_size >> Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769 >> >> The count key is the hamming weight / hweight of the bitmap. >> >> Weight, count and list accept the max and default keywords. >> >> Some DRM devices may only support lgpu as anonymous resources. >> In such case, the significance of the position of the set bits >> in list will be ignored. >> >> The weight quantity is only in effect when static allocation >> is not used (by setting count=0) for this cgroup. The weight >> quantity distributes lgpus that are not statically allocated by >> the siblings. For example, given siblings cgroupA,
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
On Fri, Feb 14, 2020 at 10:44 AM Jason Ekstrand wrote: > > Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? > What are we subdividing? Are we carving up memory? Compute power? Both? > > If it's carving up memory, why aren't we just measuring it in megabytes? > > If it's carving up compute power, what's actually being carved up? Time? > Execution units/waves/threads? Even if that's the case, what advantage does > it give to have it in terms of a fixed set of lgpus where each cgroup gets to > pick a fixed set. Does affinity matter that much? Why not just say how many > waves the GPU supports and that they have to be allocated in chunks of 16 > waves (pulling a number out of thin air) and let the cgroup specify how many > waves it wants. One more question: If I'm a userspace driver, and there are 14 lgpus allocated to my cgroup, does that mean I have 14 GPUs? Or does that mean I have one GPU with 14 units of compute power? > Don't get me wrong here. I'm all for the notion of being able to use cgroups > to carve up GPU compute resources. However, this sounds to me like the most > AMD-specific solution possible. We (Intel) could probably do some sort of > carving up as well but we'd likely want to do it with preemption and > time-slicing rather than handing out specific EUs. Ok, so "most AMD-specific solution possible" probably wasn't fair. However, it does seem like an unnecessarily rigid solution to me. Maybe there's something I'm not getting? --Jason > --Jason > > > On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: >> >> drm.lgpu >> A read-write nested-keyed file which exists on all cgroups. >> Each entry is keyed by the DRM device's major:minor. >> >> lgpu stands for logical GPU, it is an abstraction used to >> subdivide a physical DRM device for the purpose of resource >> management. This file stores user configuration while the >> drm.lgpu.effective reflects the actual allocation after >> considering the relationship between the cgroups and their >> configurations. >> >> The lgpu is a discrete quantity that is device specific (i.e. >> some DRM devices may have 64 lgpus while others may have 100 >> lgpus.) The lgpu is a single quantity that can be allocated >> in three different ways denoted by the following nested keys. >> >> = == >> weightAllocate by proportion in relationship with >> active sibling cgroups >> count Allocate by amount statically, treat lgpu as >> anonymous resources >> list Allocate statically, treat lgpu as named >> resource >> = == >> >> For example: >> 226:0 weight=100 count=256 list=0-255 >> 226:1 weight=100 count=4 list=0,2,4,6 >> 226:2 weight=100 count=32 list=32-63 >> 226:3 weight=100 count=0 list= >> 226:4 weight=500 count=0 list= >> >> lgpu is represented by a bitmap and uses the bitmap_parselist >> kernel function so the list key input format is a >> comma-separated list of decimal numbers and ranges. >> >> Consecutively set bits are shown as two hyphen-separated decimal >> numbers, the smallest and largest bit numbers set in the range. >> Optionally each range can be postfixed to denote that only parts >> of it should be set. The range will divided to groups of >> specific size. >> Syntax: range:used_size/group_size >> Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769 >> >> The count key is the hamming weight / hweight of the bitmap. >> >> Weight, count and list accept the max and default keywords. >> >> Some DRM devices may only support lgpu as anonymous resources. >> In such case, the significance of the position of the set bits >> in list will be ignored. >> >> The weight quantity is only in effect when static allocation >> is not used (by setting count=0) for this cgroup. The weight >> quantity distributes lgpus that are not statically allocated by >> the siblings. For example, given siblings cgroupA, cgroupB and >> cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies >> 0-63, no lgpu is available to be distributed by weight. >> Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63, >> cgroupC will be starved if it tries to allocate by weight. >> >> On the other hand, if cgroupA has weight=100 count=0, cgroupB >> has list=16-47, and cgroupC has weight=100 count=0, then 32 >> lgpus are available to be distributed evenly between cgroupA >> and cgroupC. In drm.lgpu.effective, cgroupA will have >> list=0-15 and cgroupC will have list=48-63. >> >> This lgpu resource supports the 'allocation' and 'weight'
Re: [PATCH 09/11] drm, cgroup: Introduce lgpu as DRM cgroup resource
Pardon my ignorance but I'm a bit confused by this. What is a "logical GPU"? What are we subdividing? Are we carving up memory? Compute power? Both? If it's carving up memory, why aren't we just measuring it in megabytes? If it's carving up compute power, what's actually being carved up? Time? Execution units/waves/threads? Even if that's the case, what advantage does it give to have it in terms of a fixed set of lgpus where each cgroup gets to pick a fixed set. Does affinity matter that much? Why not just say how many waves the GPU supports and that they have to be allocated in chunks of 16 waves (pulling a number out of thin air) and let the cgroup specify how many waves it wants. Don't get me wrong here. I'm all for the notion of being able to use cgroups to carve up GPU compute resources. However, this sounds to me like the most AMD-specific solution possible. We (Intel) could probably do some sort of carving up as well but we'd likely want to do it with preemption and time-slicing rather than handing out specific EUs. --Jason On Fri, Feb 14, 2020 at 9:57 AM Kenny Ho wrote: > drm.lgpu > A read-write nested-keyed file which exists on all cgroups. > Each entry is keyed by the DRM device's major:minor. > > lgpu stands for logical GPU, it is an abstraction used to > subdivide a physical DRM device for the purpose of resource > management. This file stores user configuration while the > drm.lgpu.effective reflects the actual allocation after > considering the relationship between the cgroups and their > configurations. > > The lgpu is a discrete quantity that is device specific (i.e. > some DRM devices may have 64 lgpus while others may have 100 > lgpus.) The lgpu is a single quantity that can be allocated > in three different ways denoted by the following nested keys. > > = == > weightAllocate by proportion in relationship with > active sibling cgroups > count Allocate by amount statically, treat lgpu as > anonymous resources > list Allocate statically, treat lgpu as named > resource > = == > > For example: > 226:0 weight=100 count=256 list=0-255 > 226:1 weight=100 count=4 list=0,2,4,6 > 226:2 weight=100 count=32 list=32-63 > 226:3 weight=100 count=0 list= > 226:4 weight=500 count=0 list= > > lgpu is represented by a bitmap and uses the bitmap_parselist > kernel function so the list key input format is a > comma-separated list of decimal numbers and ranges. > > Consecutively set bits are shown as two hyphen-separated decimal > numbers, the smallest and largest bit numbers set in the range. > Optionally each range can be postfixed to denote that only parts > of it should be set. The range will divided to groups of > specific size. > Syntax: range:used_size/group_size > Example: 0-1023:2/256 ==> 0,1,256,257,512,513,768,769 > > The count key is the hamming weight / hweight of the bitmap. > > Weight, count and list accept the max and default keywords. > > Some DRM devices may only support lgpu as anonymous resources. > In such case, the significance of the position of the set bits > in list will be ignored. > > The weight quantity is only in effect when static allocation > is not used (by setting count=0) for this cgroup. The weight > quantity distributes lgpus that are not statically allocated by > the siblings. For example, given siblings cgroupA, cgroupB and > cgroupC for a DRM device that has 64 lgpus, if cgroupA occupies > 0-63, no lgpu is available to be distributed by weight. > Similarly, if cgroupA has list=0-31 and cgroupB has list=16-63, > cgroupC will be starved if it tries to allocate by weight. > > On the other hand, if cgroupA has weight=100 count=0, cgroupB > has list=16-47, and cgroupC has weight=100 count=0, then 32 > lgpus are available to be distributed evenly between cgroupA > and cgroupC. In drm.lgpu.effective, cgroupA will have > list=0-15 and cgroupC will have list=48-63. > > This lgpu resource supports the 'allocation' and 'weight' > resource distribution model. > > drm.lgpu.effective > A read-only nested-keyed file which exists on all cgroups. > Each entry is keyed by the DRM device's major:minor. > > lgpu stands for logical GPU, it is an abstraction used to > subdivide a physical DRM device for the purpose of resource > management. This file reflects the actual allocation after > considering the relationship between the cgroups and their > configurations in drm.lgpu. > > Change-Id: Idde0ef9a331fd67bb9c7eb8ef9978439e6452488 >
