On Thu 12-01-23 07:56:31, Shakeel Butt wrote: > On Wed, Jan 11, 2023 at 11:56:45PM +0100, Daniel Vetter wrote: > > > [...] > > I think eventually, at least for other "account gpu stuff in cgroups" use > > case we do want to actually charge the memory. > > > > The problem is a bit that with gpu allocations reclaim is essentially "we > > pass the error to userspace and they get to sort the mess out". There are > > some exceptions (some gpu drivers to have shrinkers) would we need to make > > sure these shrinkers are tied into the cgroup stuff before we could enable > > charging for them? > > > > No, there is no requirement to have shrinkers or making such memory > reclaimable before charging it. Though existing shrinkers and the > possible future shrinkers would need to be converted into memcg aware > shrinkers. > > Though there will be a need to update user expectations that if they > use memcgs with hard limits, they may start seeing memcg OOMs after the > charging of dmabuf. Agreed. This wouldn't be the first in kernel memory charged memory that is not directly reclaimable. With a dedicated counter an excessive dmabuf usage would be visible in the oom report because we do print memcg stats. It is definitely preferable to have a shrinker mechanism but if that is to be done in a follow up step then this is acceptable. But leaving out charging from early on sounds like a bad choice to me. -- Michal Hocko SUSE Labs
