From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26D78C35242 for ; Tue, 11 Feb 2020 18:20:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A06A120708 for ; Tue, 11 Feb 2020 18:20:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="aLYA6QD7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A06A120708 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3E3856B030C; Tue, 11 Feb 2020 13:20:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 393F26B030D; Tue, 11 Feb 2020 13:20:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AA166B030E; Tue, 11 Feb 2020 13:20:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0019.hostedemail.com [216.40.44.19]) by kanga.kvack.org (Postfix) with ESMTP id 1272C6B030C for ; Tue, 11 Feb 2020 13:20:58 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B1ED645B4 for ; Tue, 11 Feb 2020 18:20:57 +0000 (UTC) X-FDA: 76478662554.18.lock22_256601829bd1a X-HE-Tag: lock22_256601829bd1a X-Filterd-Recvd-Size: 4773 Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Tue, 11 Feb 2020 18:20:56 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id d5so8705601qto.0 for ; Tue, 11 Feb 2020 10:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=d6/Te+6lAVYFK89u5s4ITvONIuwvEzCRENBRMlel8AM=; b=aLYA6QD7r8l7BRmVYCdYFhLJ6+BTNSmfcsvcr1NKaO2FUg7e2sB0f5KZcSPi6p74nR 6O933w7cbNN+FMz4YGCHH4AVN9pElo92zZlPlGuW0gSBq93BAPgEVr601eiAKnaapD/P GrnClfjV4wYOcuftH0Q5ekckpEe3ICyZVzmuNt9p75AlrUcLSUbK/YzbcYm34mH8OxqT SfQIEy8AuBFAXjI1EbnHUegO1y6lcC3eyPs+Uqaoqt4qUKVp8fvgx9LN7qxXVuWu884y xs/XxkT5R1DXkbm4qW8hogIMuJAsKO58D/GM+ADGdFgzSYgN2zco6ccBy5HHxO5WoFvi 2Zwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=d6/Te+6lAVYFK89u5s4ITvONIuwvEzCRENBRMlel8AM=; b=qqVzbKAPXFrCRFm1EYWE/H6csFScbJB9MxWndr4nzRuER6RYpofl5DkLl5MoboZooL yA1Hsda2ICYDpv5Dp5N6D9VUffEcGXlGRuYROy3fs8/on94E2z7grXox7rBltnB6/gbl dVcQnk3mPCVn5ckp6Y3jyln+Dka7v3QT7RLi/GJJhF1cX69m3Ap34+mRfZSCpWHKkd59 CK2zcnZu/Qw9jREhZOl6jMY8uyOUL51BoaSnlMKWp74nisMSAPxdx3btY7+BYRc4kv3Q oAThxEsz5HjxKzyijw/yMkRwNkhKmLR8XogGRTnnLAPtRc1oQDz3hrjD3xknaWdJPdQj GtjA== X-Gm-Message-State: APjAAAXDFSxOJMa6meitHftvikRxwCtCA17UhIyz4yPxnShAeimUJWwd BVaCWcPVOb9f9Y0u+1l1ZxKNCA== X-Google-Smtp-Source: APXvYqwDVs8B12ktsqqe14aSoG5G5O9rjJ6O2GFDhj+2bdU0bqJzMwN1LLweA+J2YzGHbm2yyex9eQ== X-Received: by 2002:ac8:4410:: with SMTP id j16mr3712001qtn.261.1581445256183; Tue, 11 Feb 2020 10:20:56 -0800 (PST) Received: from localhost ([2620:10d:c091:500::3:3189]) by smtp.gmail.com with ESMTPSA id r37sm2562886qtj.44.2020.02.11.10.20.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Feb 2020 10:20:55 -0800 (PST) Date: Tue, 11 Feb 2020 13:20:54 -0500 From: Johannes Weiner To: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Dave Chinner , Yafang Shao , Michal Hocko , Roman Gushchin , Andrew Morton , Linus Torvalds , Al Viro , kernel-team@fb.com Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Message-ID: <20200211182054.GA178155@cmpxchg.org> References: <20200211175507.178100-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200211175507.178100-1-hannes@cmpxchg.org> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Feb 11, 2020 at 12:55:07PM -0500, Johannes Weiner wrote: > However, this change had to be reverted in 69056ee6a8a3 ("Revert "mm: > don't reclaim inodes with many attached pages"") because it caused > severe reclaim performance problems: Inodes that sit on the shrinker > LRU are attracting reclaim pressure away from the page cache and > toward the VFS. If we then permanently exempt sizable portions of this > pool from actually getting reclaimed when looked at, this pressure > accumulates as deferred shrinker work (a mechanism for *temporarily* > unreclaimable objects) until it causes mayhem in the VFS cache pools. > > In the bug quoted in 69056ee6a8a3 in particular, the excessive > pressure drove the XFS shrinker into dirty objects, where it caused > synchronous, IO-bound stalls, even as there was plenty of clean page > cache that should have been reclaimed instead. A note on testing: the patch behaves much better on my machine and the inode shrinker doesn't drop hot page cache anymore, without noticable downsides so far. However, I tried to reproduce the xfs case that caused the 69056ee6a8a3 revert and haven't managed to do so yet on 5.5 plus the reverted patch. I cannot provoke higher inode sync stalls in the xfs shrinker regardless of shrinker strategy. Maybe something else changed since 4.19 and it's less of a concern now. Nonetheless, I'm interested in opinions on the premise of this patch. And Yafang is working on his memcg-specific fix for this issue, so I wanted to put this proposal on the table sooner than later. Thanks