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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 786BCC433F5 for ; Tue, 8 Mar 2022 17:27:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 022238D000B; Tue, 8 Mar 2022 12:27:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F130A8D0001; Tue, 8 Mar 2022 12:27:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E02AE8D000B; Tue, 8 Mar 2022 12:27:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id D140C8D0001 for ; Tue, 8 Mar 2022 12:27:40 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A7ABA24BBE for ; Tue, 8 Mar 2022 17:27:40 +0000 (UTC) X-FDA: 79221901080.12.E3A6251 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf26.hostedemail.com (Postfix) with ESMTP id 00ABF140002 for ; Tue, 8 Mar 2022 17:27:39 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 889BFB8199F; Tue, 8 Mar 2022 17:27:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45E63C340EB; Tue, 8 Mar 2022 17:27:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646760455; bh=Wyo7DT2LJqEn+VENd6dCx837uI7HnqAB2NMm453HARc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dM3LX4E3Qz2mCJs1OHF05HvFyJsXPwfK12g/YyBr9000rhGAq4e5fs4GHZ+vYJO2I iEwMLBkTqGImqGhmTWvmELXgLU+flvjC5qVaCuNSk/SK+MH5cCDLcdW0RrKLIydWEq Ls62QOa+hahmahJmMj7KACEMhGwO914/OtLqbj4y5OJzW4Ca5QgUBpvGjTerxD7siH pm3Dw4DPbIHgD1T2kHs+MopokIKVssFgGej0bi8qrRsidue/qdjNoCprDzjFt6oBlW dMgPF+Wa2U1E0QNV4/m43xQ1xonN/sTGRRy7u8wtDI3F3QXmt4WSCEgws4AztjIefd 9Qca7ysLr1XOQ== Date: Tue, 8 Mar 2022 09:27:34 -0800 From: "Darrick J. Wong" To: Christoph Hellwig Cc: Hugh Dickins , Andrew Morton , Mikulas Patocka , Zdenek Kabelac , Lukas Czerner , Miklos Szeredi , Borislav Petkov , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH mmotm v2] tmpfs: do not allocate pages on read Message-ID: <20220308172734.GC1479066@magnolia> References: <20220306092709.GA22883@lst.de> <90bc5e69-9984-b5fa-a685-be55f2b64b@google.com> <20220307064434.GA31680@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220307064434.GA31680@lst.de> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 00ABF140002 X-Stat-Signature: 4k6ekufuw84mg53bx9x6rzkkcug7jztu Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dM3LX4E3; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of djwong@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=djwong@kernel.org X-HE-Tag: 1646760459-836263 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 Mon, Mar 07, 2022 at 07:44:34AM +0100, Christoph Hellwig wrote: > On Sun, Mar 06, 2022 at 02:59:05PM -0800, Hugh Dickins wrote: > > Mikulas asked in > > https://lore.kernel.org/linux-mm/alpine.LRH.2.02.2007210510230.6959@file01.intranet.prod.int.rdu2.redhat.com/ > > Do we still need a0ee5ec520ed ("tmpfs: allocate on read when stacked")? > > > > Lukas noticed this unusual behavior of loop device backed by tmpfs in > > https://lore.kernel.org/linux-mm/20211126075100.gd64odg2bcptiqeb@work/ > > > > Normally, shmem_file_read_iter() copies the ZERO_PAGE when reading holes; > > but if it looks like it might be a read for "a stacking filesystem", it > > allocates actual pages to the page cache, and even marks them as dirty. > > And reads from the loop device do satisfy the test that is used. > > > > This oddity was added for an old version of unionfs, to help to limit > > its usage to the limited size of the tmpfs mount involved; but about > > the same time as the tmpfs mod went in (2.6.25), unionfs was reworked > > to proceed differently; and the mod kept just in case others needed it. > > > > Do we still need it? I cannot answer with more certainty than "Probably > > not". It's nasty enough that we really should try to delete it; but if > > a regression is reported somewhere, then we might have to revert later. > > > > It's not quite as simple as just removing the test (as Mikulas did): > > xfstests generic/013 hung because splice from tmpfs failed on page not > > up-to-date and page mapping unset. That can be fixed just by marking > > the ZERO_PAGE as Uptodate, which of course it is: do so in > > pagecache_init() - it might be useful to others than tmpfs. > > > > My intention, though, was to stop using the ZERO_PAGE here altogether: > > surely iov_iter_zero() is better for this case? Sadly not: it relies > > on clear_user(), and the x86 clear_user() is slower than its copy_user(): > > https://lore.kernel.org/lkml/2f5ca5e4-e250-a41c-11fb-a7f4ebc7e1c9@google.com/ > > > > But while we are still using the ZERO_PAGE, let's stop dirtying its > > struct page cacheline with unnecessary get_page() and put_page(). > > > > Reported-by: Mikulas Patocka > > Reported-by: Lukas Czerner > > Signed-off-by: Hugh Dickins > > I would have split the uptodate setting of ZERO_PAGE into a separate, > clearly documented patch, but otherwise this looks good: > > Reviewed-by: Christoph Hellwig I've long wondered (for my own nefarious purposes) why tmpfs files didn't just grab the zero page, so: Acked-by: Darrick J. Wong --D