On Fri, Sep 5, 2025 at 2:25 PM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote: > > On Thu, Sep 04, 2025 at 01:21:47PM -0700, Kuniyuki Iwashima wrote: > > On Wed, Sep 3, 2025 at 11:35 PM Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > > > > > On Wed, Sep 03, 2025 at 07:02:03PM +0000, Kuniyuki Iwashima wrote: > > > > If all workloads were guaranteed to be controlled under memcg, the issue > > > > could be worked around by setting tcp_mem[0~2] to UINT_MAX. > > > > > > > > In reality, this assumption does not always hold, and processes not > > > > controlled by memcg lose the seatbelt and can consume memory up to > > > > the global limit, becoming noisy neighbour. > > > > > > It's been repeatedly pointed out to you that this container > > > configuration is not, and cannot be, supported. Processes not > > > controlled by memcg have many avenues to become noisy neighbors in a > > > multi-tenant system. > > > > > > So my NAK still applies. Please carry this forward in all future patch > > > submissions even if your implementation changes. > > > > I see. > > > > I'm waiting for Shakeel's response as he agreed on decoupling > > memcg and tcp_mem and suggested the bpf approach. > > Yes I agreed on decoupling memcg and tcp_mem but not for a weird > configuration, so please stop using this motivatioan already. You can > motivate the decoupling simply on performance. Why pay the cost > of two orthogonal accounting mechanisms concurrently? Also you are not > disabling memcg accounting, so we should be good from memcg side. Make > this very clear in your commit message. > > I don't care how you plan to use this feature to enable your weird > use-case but make sure this feature is beneficial to general Linux > users. Thank you Shakeel, I will rephrase the commit messages and clarify the points above.
