On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote:
> On Fri 06-09-19 08:45:39, Tejun Heo wrote:
> > Hello, Daniel.
> >
> > On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > > > Hmm... what'd be the fundamental difference from slab or socket memory
> > > > which are hand
On Tue 10-09-19 09:03:29, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote:
> > > So, while it'd great to have shrinkers in the longer term, it's not a
> > > strict requirement to be accounted in memcg. It already accounts a
> > > lot of memory wh
Hello, Michal.
On Tue, Sep 10, 2019 at 01:54:48PM +0200, Michal Hocko wrote:
> > So, while it'd great to have shrinkers in the longer term, it's not a
> > strict requirement to be accounted in memcg. It already accounts a
> > lot of memory which isn't reclaimable (a lot of slabs and socket
> > bu
On Fri 06-09-19 08:45:39, Tejun Heo wrote:
> Hello, Daniel.
>
> On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > > Hmm... what'd be the fundamental difference from slab or socket memory
> > > which are handled through memcg? Is system memory used by GPUs have
> > > further globa
Hello, Daniel.
On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > Hmm... what'd be the fundamental difference from slab or socket memory
> > which are handled through memcg? Is system memory used by GPUs have
> > further global restrictions in addition to the amount of physical
>
On Fri, Sep 6, 2019 at 5:23 PM Tejun Heo wrote:
>
> Hello, Daniel.
>
> On Tue, Sep 03, 2019 at 09:48:22PM +0200, Daniel Vetter wrote:
> > I think system memory separate from vram makes sense. For one, vram is
> > like 10x+ faster than system memory, so we definitely want to have
> > good control o
Hello, Daniel.
On Tue, Sep 03, 2019 at 09:48:22PM +0200, Daniel Vetter wrote:
> I think system memory separate from vram makes sense. For one, vram is
> like 10x+ faster than system memory, so we definitely want to have
> good control on that. But maybe we only want one vram bucket overall
> for t
On Tue, Sep 3, 2019 at 8:50 PM Tejun Heo wrote:
>
> Hello, Daniel.
>
> On Tue, Sep 03, 2019 at 09:55:50AM +0200, Daniel Vetter wrote:
> > > * While breaking up and applying control to different types of
> > > internal objects may seem attractive to folks who work day in and
> > > day out with
On Tue, Sep 3, 2019 at 5:20 AM Daniel Vetter wrote:
>
> On Tue, Sep 3, 2019 at 10:24 AM Koenig, Christian
> wrote:
> >
> > Am 03.09.19 um 10:02 schrieb Daniel Vetter:
> > > On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
> > >> With this RFC v4, I am hoping to have some consensus on a m
Hi Tejun,
Thanks for looking into this. I can definitely help where I can and I
am sure other experts will jump in if I start misrepresenting the
reality :) (as Daniel already have done.)
Regarding your points, my understanding is that there isn't really a
TTM vs GEM situation anymore (there is
Hello, Daniel.
On Tue, Sep 03, 2019 at 09:55:50AM +0200, Daniel Vetter wrote:
> > * While breaking up and applying control to different types of
> > internal objects may seem attractive to folks who work day in and
> > day out with the subsystem, they aren't all that useful to users and
> >
On Tue, Sep 3, 2019 at 10:24 AM Koenig, Christian
wrote:
>
> Am 03.09.19 um 10:02 schrieb Daniel Vetter:
> > On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
> >> This is a follow up to the RFC I made previously to introduce a cgroup
> >> controller for the GPU/DRM subsystem [v1,v2,v3].
Am 03.09.19 um 10:02 schrieb Daniel Vetter:
> On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
>> This is a follow up to the RFC I made previously to introduce a cgroup
>> controller for the GPU/DRM subsystem [v1,v2,v3]. The goal is to be able to
>> provide resource management to GPU reso
On Thu, Aug 29, 2019 at 02:05:17AM -0400, Kenny Ho wrote:
> This is a follow up to the RFC I made previously to introduce a cgroup
> controller for the GPU/DRM subsystem [v1,v2,v3]. The goal is to be able to
> provide resource management to GPU resources using things like container.
>
> With th
On Fri, Aug 30, 2019 at 09:28:57PM -0700, Tejun Heo wrote:
> Hello,
>
> I just glanced through the interface and don't have enough context to
> give any kind of detailed review yet. I'll try to read up and
> understand more and would greatly appreciate if you can give me some
> pointers to read u
Hello,
I just glanced through the interface and don't have enough context to
give any kind of detailed review yet. I'll try to read up and
understand more and would greatly appreciate if you can give me some
pointers to read up on the resources being controlled and how the
actual use cases would
This is a follow up to the RFC I made previously to introduce a cgroup
controller for the GPU/DRM subsystem [v1,v2,v3]. The goal is to be able to
provide resource management to GPU resources using things like container.
With this RFC v4, I am hoping to have some consensus on a merge plan. I be
17 matches
Mail list logo
