On Mon, May 28, 2018 at 2:11 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Sat 26-05-18 15:37:05, Shakeel Butt wrote: >> On Sat, May 26, 2018 at 11:51 AM, Vladimir Davydov >> <vdavydov.dev@xxxxxxxxx> wrote: >> > On Fri, May 25, 2018 at 11:55:01AM -0700, Shakeel Butt wrote: >> >> Based on several conditions the kernel can decide to force charge an >> >> allocation for a memcg i.e. overcharge memcg->memory and memcg->memsw >> >> counters. Do the same for memcg->kmem counter too. In cgroup-v1, this >> >> bug can cause a __GFP_NOFAIL kmem allocation fail if an explicit limit >> >> on kmem counter is set and reached. >> > >> > memory.kmem.limit is broken and unlikely to ever be fixed as this knob >> > was deprecated in cgroup-v2. The fact that hitting the limit doesn't >> > trigger reclaim can result in unexpected behavior from user's pov, like >> > getting ENOMEM while listing a directory. Bypassing the limit for NOFAIL >> > allocations isn't going to fix those problem. >> >> I understand that fixing NOFAIL will not fix all other issues but it >> still is better than current situation. IMHO we should keep fixing >> kmem bit by bit. >> >> One crazy idea is to just break it completely by force charging all the time. > > What is the limit good for then? Accounting? > Unlike tcpmem, the kmem accounting is enabled by default. No need to set the limit to enable accounting. I think my crazy idea was just wrong and without much thought. Though is there a precedence where the broken feature is not fixed because an alternative is available?
