From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by kanga.kvack.org (Postfix) with ESMTP id 585798E0002 for ; Wed, 16 Jan 2019 02:06:17 -0500 (EST) Received: by mail-ed1-f70.google.com with SMTP id t7so1995052edr.21 for ; Tue, 15 Jan 2019 23:06:17 -0800 (PST) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id r19si5241406edl.68.2019.01.15.23.06.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jan 2019 23:06:16 -0800 (PST) Date: Wed, 16 Jan 2019 08:06:14 +0100 From: Michal Hocko Subject: Re: memory cgroup pagecache and inode problem Message-ID: <20190116070614.GG24149@dhcp22.suse.cz> References: <15614FDC-198E-449B-BFAF-B00D6EF61155@bytedance.com> <97A4C2CA-97BA-46DB-964A-E44410BB1730@bytedance.com> <9B56B884-8FDD-4BB5-A6CA-AD7F84397039@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Fam Zheng Cc: Yang Shi , cgroups@vger.kernel.org, Linux MM , tj@kernel.org, Johannes Weiner , lizefan@huawei.com, Vladimir Davydov , duanxiongchun@bytedance.com, =?utf-8?B?5byg5rC46IKD?= , liuxiaozhou@bytedance.com On Wed 16-01-19 11:52:08, Fam Zheng wrote: [...] > > This is what force_empty is supposed to do. But, as your test shows > > some page cache may still remain after force_empty, then cause offline > > memcgs accumulated. I haven't figured out what happened. You may try > > what Michal suggested. > > None of the existing patches helped so far, but we suspect that the > pages cannot be locked at the force_empty moment. We have being > working on a “retry” patch which does solve the problem. We’ll > do more tracing (to have a better understanding of the issue) and post > the findings and/or the patch later. Thanks. Just for the record. There was a patch to remove MEM_CGROUP_RECLAIM_RETRIES restriction in the path. I cannot find the link right now but that is something we certainly can do. The context is interruptible by signal and it from my experience any retry count can lead to unexpected failures. But I guess you really want to check vmscan tracepoints to see why you cannot reclaim pages on memcg LRUs first. -- Michal Hocko SUSE Labs