Quoting Kuehling, Felix (2018-12-03 22:55:16)
>
> On 2018-11-28 4:14 a.m., Joonas Lahtinen wrote:
> > Quoting Ho, Kenny (2018-11-27 17:41:17)
> >> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
> >> wrote:
> >>> I think a more abstract property "% of GPU (processing power)" might
> >>> be a mor
On 2018-11-28 4:14 a.m., Joonas Lahtinen wrote:
> Quoting Ho, Kenny (2018-11-27 17:41:17)
>> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
>> wrote:
>>> I think a more abstract property "% of GPU (processing power)" might
>>> be a more universal approach. One can then implement that through
>>
On Mon, Dec 03, 2018 at 06:46:01AM +, Ho, Kenny wrote:
> Hey Matt,
>
> On Fri, Nov 30, 2018 at 5:22 PM Matt Roper wrote:
> > I think Joonas is describing something closer in
> > design to the cgroup-v2 "cpu" controller, which partitions the general
> > time/usage allocated to via cgroup; afai
Hey Matt,
On Fri, Nov 30, 2018 at 5:22 PM Matt Roper wrote:
> I think Joonas is describing something closer in
> design to the cgroup-v2 "cpu" controller, which partitions the general
> time/usage allocated to via cgroup; afaiu, "cpu" doesn't really care
> which specific core the tasks run on, ju
On Wed, Nov 28, 2018 at 07:46:06PM +, Ho, Kenny wrote:
>
> On Wed, Nov 28, 2018 at 4:14 AM Joonas Lahtinen
> wrote:
> > 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
On Wed, Nov 28, 2018 at 4:14 AM Joonas Lahtinen
wrote:
> 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?
I don't think having an abstracted res
Quoting Ho, Kenny (2018-11-27 17:41:17)
> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
> wrote:
> > 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, depe
On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
wrote:
> 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/
Quoting Kasiviswanathan, Harish (2018-11-26 22:59:30)
> Thanks Tejun,Eric and Christian for your replies.
>
> We want GPUs resource management to work seamlessly with containers and
> container orchestration. With the Intel / bpf based approach this is not
> possible.
>
> From your response we
Hi Harish,
Am 26.11.18 um 21:59 schrieb Kasiviswanathan, Harish:
> Thanks Tejun,Eric and Christian for your replies.
>
> We want GPUs resource management to work seamlessly with containers and
> container orchestration. With the Intel / bpf based approach this is not
> possible.
I think one les
Thanks Tejun,Eric and Christian for your replies.
We want GPUs resource management to work seamlessly with containers and
container orchestration. With the Intel / bpf based approach this is not
possible.
From your response we gather the following. GPU resources need to be
abstracted. We will
Am 20.11.18 um 19:58 schrieb Kenny Ho:
Since many parts of the DRM subsystem has vendor-specific
implementations, we introduce mechanisms for vendor to register their
specific resources and control files to the DRM cgroup subsystem. A
vendor will register itself with the DRM cgroup subsystem fir
Hi Tejun,
Thanks for the reply. A few clarifying questions:
On Tue, Nov 20, 2018 at 3:21 PM Tejun Heo wrote:
> So, I'm still pretty negative about adding drm controller at this
> point. There isn't enough of common resource model defined yet and
> until that gets sorted out I think it's in the
Since many parts of the DRM subsystem has vendor-specific
implementations, we introduce mechanisms for vendor to register their
specific resources and control files to the DRM cgroup subsystem. A
vendor will register itself with the DRM cgroup subsystem first before
registering individual DRM devi
Hello,
On Tue, Nov 20, 2018 at 10:21:14PM +, Ho, Kenny wrote:
> 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 clea
Hello,
On Tue, Nov 20, 2018 at 01:58:11PM -0500, Kenny Ho wrote:
> Since many parts of the DRM subsystem has vendor-specific
> implementations, we introduce mechanisms for vendor to register their
> specific resources and control files to the DRM cgroup subsystem. A
> vendor will register itself
16 matches
Mail list logo
