On Fri, May 24, 2019 at 09:11:46AM -0700, Matthew Wilcox wrote: > On Thu, May 23, 2019 at 03:59:33PM -0400, Johannes Weiner wrote: > > My point is that we cannot have random drivers' internal data > > structures charge to and pin cgroups indefinitely just because they > > happen to do the modprobing or otherwise interact with the driver. > > > > It makes no sense in terms of performance or cgroup semantics. > > But according to Roman, you already have that problem with the page > cache. > https://lore.kernel.org/linux-mm/20190522222254.GA5700@castle/T/ > > So this argument doesn't make sense to me. You haven't addressed the rest of the argument though: why every user of the xarray, and data structures based on it, should incur the performance cost of charging memory to a cgroup, even when we have no interest in tracking those allocations on behalf of a cgroup. Which brings me to repeating the semantics argument: it doesn't make sense to charge e.g. driver memory, which is arguably a shared system resource, to whoever cgroup happens to do the modprobe / ioctl etc. Anyway, this seems like a fairly serious regression, and it would make sense to find a self-contained, backportable fix instead of something that has subtle implications for every user of the xarray / ida code.
