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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 65C26C433E0 for ; Mon, 15 Mar 2021 23:43:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DAD9164E86 for ; Mon, 15 Mar 2021 23:43:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DAD9164E86 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5FB3D6B0036; Mon, 15 Mar 2021 19:43:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 583616B006C; Mon, 15 Mar 2021 19:43:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FDFB6B0070; Mon, 15 Mar 2021 19:43:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id 1F0A26B0036 for ; Mon, 15 Mar 2021 19:43:50 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A90D41801323F for ; Mon, 15 Mar 2021 23:43:49 +0000 (UTC) X-FDA: 77923738578.25.DCB6376 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf06.hostedemail.com (Postfix) with ESMTP id C8C78C000636 for ; Mon, 15 Mar 2021 23:41:39 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 98AF864F5E; Mon, 15 Mar 2021 23:41:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1615851698; bh=ZRw4LBv8GBdf5Sggo16rGV3091lb93cVl67xHbNT2sI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MKiRV5vMH9JlAlXD4ZUmR+e8lrd5u8nHdUPWTZJzi+ZFniCOUKLm4Mk7b+WF+22Xa sg7IUeo+f+EtjPEnf6/nKIYmoeeWU/Y7FveVfj6I4hFPkzbC07ZMVrmaD2QdZnoY2U QGk6jX5TQ9wkj5oOZBNuj7tw7mQfl86O2C6ATslU= Date: Mon, 15 Mar 2021 16:41:38 -0700 From: Andrew Morton To: Chris Goldsworthy Cc: Alexander Viro , Matthew Wilcox , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Laura Abbott Subject: Re: [PATCH v3] fs/buffer.c: Revoke LRU when trying to drop buffers Message-Id: <20210315164138.c15727adeb184313f5e7e9f6@linux-foundation.org> In-Reply-To: <2f13c006ad12b047e9e4d5de008e5d5c41322754.1610572007.git.cgoldswo@codeaurora.org> References: <2f13c006ad12b047e9e4d5de008e5d5c41322754.1610572007.git.cgoldswo@codeaurora.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: p8ycqcq56sdqqt9ohkgfrgrqnj5efxxs X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: C8C78C000636 Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615851699-633932 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, 13 Jan 2021 13:17:30 -0800 Chris Goldsworthy wrote: > From: Laura Abbott > > When a buffer is added to the LRU list, a reference is taken which is > not dropped until the buffer is evicted from the LRU list. This is the > correct behavior, however this LRU reference will prevent the buffer > from being dropped. This means that the buffer can't actually be dropped > until it is selected for eviction. There's no bound on the time spent > on the LRU list, which means that the buffer may be undroppable for > very long periods of time. Given that migration involves dropping > buffers, the associated page is now unmigratible for long periods of > time as well. CMA relies on being able to migrate a specific range > of pages, so these types of failures make CMA significantly > less reliable, especially under high filesystem usage. > > Rather than waiting for the LRU algorithm to eventually kick out > the buffer, explicitly remove the buffer from the LRU list when trying > to drop it. There is still the possibility that the buffer > could be added back on the list, but that indicates the buffer is > still in use and would probably have other 'in use' indicates to > prevent dropping. > > Note: a bug reported by "kernel test robot" lead to a switch from > using xas_for_each() to xa_for_each(). (hm, why isn't drop_buffers() static to fs/buffer.c??) It looks like patch this turns drop_buffers() into a very expensive operation. And that expensive operation occurs under the address_space-wide private_lock, which is more ouch. How carefully has this been tested for performance? In pathological circumstances (which are always someone's common case :() Just thinking out loud... If a buffer_head* is sitting in one or more of the LRUs, what is stopping us from stripping it from the page anyway? Then try_to_free_buffers() can mark the bh as buffer_dead(), declare success and leave the bh sitting in the LRU, with the LRU as the only reference to that buffer. Teach lookup_bh_lru() to skip over buffer_dead() buffers and our now-dead buffer will eventually reach the tail of the lru and get freed for real.