On 5/22/26 18:17, Tejun Heo wrote: > Hello, > > On Fri, May 22, 2026 at 05:26:16PM +0200, Michal Koutný wrote: >> Hello Eric. >> >> On Tue, May 19, 2026 at 11:59:02AM -0400, Eric Chanudet >> <[email protected]> wrote: >>> Add a root-only cgroupfs file "dmem.memcg" that lets an administrator >>> configure whether allocations in a dmem region should also be charged to >>> the memory controller. >> >> This kinda makes sense as it is not unlike io.cost.* device >> configurators. >> >> Just for my better understanding -- will there be a space for userspace >> to switch this? (No charged dmem allocations happen before responsible >> userspace runs, so that the attribute remains unlocked.) >> >> (I'm rather indifferent about the actual double charging/non-charging >> matter.) > > I wonder whether this would make more sense as a mount flag? What's the use > case for e.g. having different config for different devices? Wouldn't that > be really confusing?
>From the cloud gaming use case I can't fully rule out that we need mixed >settings for different cgroups. Making an educated guess I think the best approach would be to have a default value per dmem given by the driver who creates that dmem. Looking at AMD GPUs we have the APUs where VRAM is basically stolen system memory and dGPUs where VRAM is dedicated device memory. So what the driver detects as HW config should affect the default behavior. Regards, Christian. > > Thanks. >
