Ccing Mina who actually worked on upstreaming this. See [1] for previous discussion and more use-cases. [1] https://lore.kernel.org/linux-mm/20211120045011.3074840-1-almasrymina@xxxxxxxxxx/ On Tue, Jul 12, 2022 at 10:36 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > > Hello, > > On Tue, Jul 12, 2022 at 10:26:22AM -0700, Shakeel Butt wrote: > > One use-case we have is a build & test service which runs independent > > builds and tests but all the build utilities (compiler, linker, > > libraries) are shared between those builds and tests. > > > > In terms of topology, the service has a top level cgroup (P) and all > > independent builds and tests run in their own cgroup under P. These > > builds/tests continuously come and go. > > > > This service continuously monitors all the builds/tests running and > > may kill some based on some criteria which includes memory usage. > > However the memory usage is nondeterministic and killing a specific > > build/test may not really free memory if most of the memory charged to > > it is from shared build utilities. > > That doesn't sound too unusual. So, one saving grace here is that the memory > pressure in the stressed cgroup should trigger reclaim of the shared memory > which will be likely picked up by someone else, hopefully, under less memory > pressure. Can you give more concerete details? ie. describe a failing > scenario with actual ballpark memory numbers? Mina, can you please provide details requested by Tejun? > > FWIW, at least from generic resource constrol standpoint, I think it may > make sense to have a way to escape certain resources to an ancestor for > shared resources provided that we can come up with a sane interface. > > Thanks. > > -- > tejun
