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 B88E2C433FE for ; Wed, 12 Jan 2022 17:46:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ADB16B01F1; Wed, 12 Jan 2022 12:46:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 25D1F6B01F2; Wed, 12 Jan 2022 12:46:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1259D6B01F3; Wed, 12 Jan 2022 12:46:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0119.hostedemail.com [216.40.44.119]) by kanga.kvack.org (Postfix) with ESMTP id DB7876B01F1 for ; Wed, 12 Jan 2022 12:46:36 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5ACCF181CE291 for ; Wed, 12 Jan 2022 17:46:36 +0000 (UTC) X-FDA: 79022364792.04.2D818E0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 661CF12000D for ; Wed, 12 Jan 2022 17:46:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=2mZtHdjbIat3c+/tmBHUW44wgGkNwhsML0tnmjI65+I=; b=RWFQpGiucu82sruTzvMG5Kp2x5 uA6xG0+x4NIhbSQD75/oV0cAaJR9D9Dsbu9OeRs0NJWsjY+Iy5FpptKxDn/79BJZDuWjj0Isa6oq0 x6aX7oFUjXtDcrzIxhk3OE6X+LbJSg0RRh1290sd+516keGkvwC5fkskIVMSQjI+mpGCmldbQEBA2 1Ok/r0xBZQ6MV5EdJtKRZiSrfiyGvv/sDDnNv/+h+FByub73SBKsfvNabAU4CTQ9KP70Ab7L/7gSf DbIqNkq3/hgVDaq3YBKZUwWV7Sdhb/IrS30frtPBmTVMBuEE+kVkKOtX25W5BUU8ehdJJ0wLMv9/S F3KMtIfg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7hhX-004HsR-UV; Wed, 12 Jan 2022 17:46:23 +0000 Date: Wed, 12 Jan 2022 17:46:23 +0000 From: Matthew Wilcox To: "Darrick J. Wong" Cc: Hugh Dickins , Lukas Czerner , Mikulas Patocka , Zdenek Kabelac , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: unusual behavior of loop dev with backing file in tmpfs Message-ID: References: <20211126075100.gd64odg2bcptiqeb@work> <5e66a9-4739-80d9-5bb5-cbe2c8fef36@google.com> <20220112171937.GA19154@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220112171937.GA19154@magnolia> X-Rspamd-Queue-Id: 661CF12000D X-Stat-Signature: s447kmmp3n3fuw1ym7ieporh3y1j6rau Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=RWFQpGiu; dmarc=none; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam02 X-HE-Tag: 1642009595-333957 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, Jan 12, 2022 at 09:19:37AM -0800, Darrick J. Wong wrote: > I for one wouldn't mind if tmpfs no longer instantiated cache pages for > a read from a hole -- it's a little strange, since most disk filesystems > (well ok xfs and ext4, haven't checked the others) don't do that. > Anyone who really wants a preallocated page should probably be using > fallocate or something... We don't allocate disk blocks, but we do allocate pages. filemap_read() filemap_get_pages() page_cache_sync_readahead() page_cache_sync_ra() ondemand_readahead() do_page_cache_ra() page_cache_ra_unbounded() __page_cache_alloc() add_to_page_cache_lru() At this point, we haven't called into the filesystem, so we don't know that we're allocating pages for a hole. Although tmpfs doesn't take this path; it has its own shmem_file_read_iter() instead of calling filemap_read(). I do rather regret that because it means that tmpfs doesn't take advantage of readahead, which means that swapping back _in_ is rather slow. It's on my list of things to look at ... eventually.