On Tue 16-11-21 13:55:54, Shakeel Butt wrote: > On Tue, Nov 16, 2021 at 1:27 PM Mina Almasry <almasrymina@xxxxxxxxxx> wrote: > > > > On Tue, Nov 16, 2021 at 3:29 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > [...] > > > Yes, exactly. I meant that all this special casing would be done at the > > > shmem layer as it knows how to communicate this usecase. > > > > > > > Awesome. The more I think of it I think the ENOSPC handling is perfect > > for this use case, because it gives all users of the shared memory and > > remote chargers a chance to gracefully handle the ENOSPC or the SIGBUS > > when we hit the nothing to kill case. The only issue is finding a > > clean implementation, and if the implementation I just proposed sounds > > good to you then I see no issues and I'm happy to submit this in the > > next version. Shakeel and others I would love to know what you think > > either now or when I post the next version. > > > > The direction seems reasonable to me. I would have more comments on > the actual code. At the high level I would prefer not to expose these > cases in the filesystem code (shmem or others) and instead be done in > a new memcg interface for filesystem users. A library like function in the memcg proper sounds good to me I just want to avoid any special casing in the core of the memcg charging and special casing there. -- Michal Hocko SUSE Labs
