Re: cgroup specific sticky resources (was: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

On Tue, Jul 19, 2022 at 12:47:39PM -0700, Mina Almasry wrote:
> Hmm, sorry I might be missing something but I don't think we have the
> same thing in mind?
> 
> My understanding is that the sysadmin can do something like this which
> is relatively inexpensive to implement in the kernel:
> 
> 
> mount -t tmpfs /mnt/mymountpoint
> echo "/mnt/mymountpoint" > /path/to/cgroup/cgroup.charge_for.tmpfs
> 
> 
> At that point all tmpfs charges for this tmpfs are directed to
> /path/to/cgroup/memory.current.
> 
> Then the sysadmin can do something like:
> 
> 
> echo "/mnt/mymountpoint" > /path/to/cgroup2/cgroup.charge_for.tmpfs
> 
> 
> At that point all _future_ charges of that tmpfs will go to
> cgroup2/memory.current. All existing charges remain at
> cgroup/memory.current and get uncharged from there. Per my
> understanding there is no need to move all the _existing_ charges from
> cgroup/memory.current to cgroup2/memory.current.

So, it's a lot better if the existing charges aren't moved around but it's
also kinda confusing if something can be moved around the tree arbitrarily
leaving charges behind. We already do get that from moving processes around
but most common usages are pretty static at this point and I think it'd be
better to avoid expanding the interface in that direction.

I'd much prefer something alont the line of `mount -t tmpfs -o cgroup=XXX`
where the tmpfs code checks whether the specified cgroup is one of the
ancestors and the mounting task has enough permission to shift the resource
there.

Thanks.

-- 
tejun




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux