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 A773DC3B187 for ; Wed, 12 Feb 2020 18:52:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 088B22073C for ; Wed, 12 Feb 2020 18:52:13 +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="CeOgukl0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 088B22073C 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 624976B048E; Wed, 12 Feb 2020 13:52:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B0346B048F; Wed, 12 Feb 2020 13:52:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 476A66B0490; Wed, 12 Feb 2020 13:52:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0136.hostedemail.com [216.40.44.136]) by kanga.kvack.org (Postfix) with ESMTP id 2C34E6B048E for ; Wed, 12 Feb 2020 13:52:13 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id F35558245571 for ; Wed, 12 Feb 2020 18:52:12 +0000 (UTC) X-FDA: 76482370104.08.coil39_4d6444a94b93b X-HE-Tag: coil39_4d6444a94b93b X-Filterd-Recvd-Size: 5530 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Wed, 12 Feb 2020 18:52:11 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id c5so2400997qtj.6 for ; Wed, 12 Feb 2020 10:52:11 -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=ATjtj9uhoqbutpORm3twmVpl6WMWrzgSu/Pef3LSt8M=; b=CeOgukl06W8Hf4S1CRY2NUWa4z3u+gGuwykBw8jvgPAOCOEqPHzjcGo8O/kZffzk05 v6pDOrnWKwO2Uc0Pv9YX1Gf3iRrqs1SZe9rz76aKfncwXlCGXaX4/VL3H8LkvrFOhDl6 Q/W3RYEYvohBIFAMpqLUXnH67k2XGZf76gyo0SvoWnVwRbyTqyYt37GB5wSC2VoiiPF/ +vb+eYKGZOVcrxuDvI2ZJ5+appiYzcQnj8hBF1TDF+Bef5PGXixPhNinsokmZ0m4fFXU tK8oQWE7EEyOZ+8guuS0/DagdIi9RENopyLQ8RF+FKBFkgaLAf+f6D+ZfNhPgp1YAEdo Xkyg== 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=ATjtj9uhoqbutpORm3twmVpl6WMWrzgSu/Pef3LSt8M=; b=RMPV/KKMbyTvgiakkRE9aRVP7XJSWY9QKO9TNHrLe3uJDpO6uWHk5M1ll4Opbvwrhq KweGPj02FZVuf+IjRRqAZmFCm8AvNFcpLFrsihsLvTpGkh2mxpQKYM40NZFYZdx9cDbV VV2fDw3XV7uoBJ1oCGgDAhSGtfvE+RnHuKF9a/+Nrhj0wl/RubI1Iygcw4OPbxMcjzgU 0V8DbYqBhWeLBgPs0MV6VX9KGeyOH4B6ZW2H+z2v+4GduhM4cz0pRQUPPSysRtuGPf/b 6N7Jyui6xASlSwRlW+pEWPqJDLxNFk+lOKdWaD6KA+BY4z3m56OnlQBq0MQsSo0RkxZ8 ia8g== X-Gm-Message-State: APjAAAURZiy4xHxkaM5bmA+PhrpdBFvtjmmedvP0YCwgpKIYVdI99pME 9uO4SAKgSXFHrsVncLO7DVb9bA== X-Google-Smtp-Source: APXvYqx5Ca61AWNH6d2djo58vJ8Cb09R7uCxhUTN2gPc4ax8cB+65DSTSeMcWR0luIlwyTq0lYXeaw== X-Received: by 2002:ac8:365c:: with SMTP id n28mr8285715qtb.260.1581533530780; Wed, 12 Feb 2020 10:52:10 -0800 (PST) Received: from localhost ([2620:10d:c091:500::5a94]) by smtp.gmail.com with ESMTPSA id g53sm682746qtk.76.2020.02.12.10.52.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2020 10:52:09 -0800 (PST) Date: Wed, 12 Feb 2020 13:52:09 -0500 From: Johannes Weiner To: Andrew Morton Cc: Rik van Riel , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner , Yafang Shao , Michal Hocko , Roman Gushchin , Linus Torvalds , Al Viro , kernel-team@fb.com Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU Message-ID: <20200212185209.GA206066@cmpxchg.org> References: <20200211175507.178100-1-hannes@cmpxchg.org> <29b6e848ff4ad69b55201751c9880921266ec7f4.camel@surriel.com> <20200211193101.GA178975@cmpxchg.org> <20200211154438.14ef129db412574c5576facf@linux-foundation.org> <20200212163540.GA180867@cmpxchg.org> <20200212102645.7b2e5b228048b6d22331e47d@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200212102645.7b2e5b228048b6d22331e47d@linux-foundation.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 Wed, Feb 12, 2020 at 10:26:45AM -0800, Andrew Morton wrote: > On Wed, 12 Feb 2020 11:35:40 -0500 Johannes Weiner wrote: > > > Since the cache purging code was written for highmem scenarios, how > > about making it specific to CONFIG_HIGHMEM at least? > > Why do I have memories of suggesting this a couple of weeks ago ;) Sorry, you did. I went back and found your email now. It completely slipped my mind after that thread went off into another direction. > > That way we improve the situation for the more common setups, without > > regressing highmem configurations. And if somebody wanted to improve > > the CONFIG_HIGHMEM behavior as well, they could still do so. > > > > Somethig like the below delta on top of my patch? > > Does it need to be that complicated? What's wrong with > > --- a/fs/inode.c~a > +++ a/fs/inode.c > @@ -761,6 +761,10 @@ static enum lru_status inode_lru_isolate > return LRU_ROTATE; > } > > +#ifdef CONFIG_HIGHMEM > + /* > + * lengthy blah > + */ > if (inode_has_buffers(inode) || inode->i_data.nrpages) { > __iget(inode); > spin_unlock(&inode->i_lock); > @@ -779,6 +783,7 @@ static enum lru_status inode_lru_isolate > spin_lock(lru_lock); > return LRU_RETRY; > } > +#endif Pages can show up here even under !CONFIG_HIGHMEM. Because of the lock order to maintain LRU state (i_lock -> xa_lock), when the page cache inserts new pages it doesn't unlink the inode from the LRU atomically, and the shrinker might get here before inode_pages_set(). In that case we need the shrinker to punt the inode off the LRU (the #else branch). > WARN_ON(inode->i_state & I_NEW); > inode->i_state |= I_FREEING; > _ > > Whatever we do will need plenty of testing. It wouldn't surprise me > if there are people who unknowingly benefit from this code on > 64-bit machines. If we agree this is the way to go, I can put the patch into our tree and gather data from the Facebook fleet before we merge it.