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 57637CD11DD for ; Tue, 26 Mar 2024 13:08:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB04B6B0082; Tue, 26 Mar 2024 09:08:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5F826B0083; Tue, 26 Mar 2024 09:08:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4F256B0085; Tue, 26 Mar 2024 09:08:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B98456B0082 for ; Tue, 26 Mar 2024 09:08:34 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7DFE9C0B9E for ; Tue, 26 Mar 2024 13:08:34 +0000 (UTC) X-FDA: 81939219348.05.1193E4E Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by imf25.hostedemail.com (Postfix) with ESMTP id 8E2B7A0028 for ; Tue, 26 Mar 2024 13:08:31 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=ZpPpldsn; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf25.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711458512; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8d3EYhEfZQrAxbjR62dfoi3Du1p/pSGgH8hAUpFy1wc=; b=UmivRy3L9dSVmliTP0T8nLOHMn9qsERTRRj0XJZDxJ7cpKy/58Gf3kLTpEfR6OqYdW8+ud jD6gpvOwssCNGkUYa/yynKaE0hoY0HEOmmtvvKzQmE7wAuQhoq5VX/8YCNq9RzEbyKCAqR OU2C78PWyGKQC7GPNeD/KuS+hX/wQvM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=ZpPpldsn; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf25.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711458512; a=rsa-sha256; cv=none; b=vbXj8cvQsg8myp3b0C/fWSFb+9jMYxb3LJEhBjQZ+cBFYvgkwXwDdrwS3id3erAUIvRhAO ABn3ohrwTaG4by1TJ734HVA7TbHc8GiLiBse/boPsi8PYcYF5BMYP4q00NU9YBUn7wyZ37 AnAw8DHR1am3pUZskLjsa2YtUSXnUg4= Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4V3qqZ1vgkz9sZw; Tue, 26 Mar 2024 14:08:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1711458506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8d3EYhEfZQrAxbjR62dfoi3Du1p/pSGgH8hAUpFy1wc=; b=ZpPpldsnkTVp8fEwuvWULTRBSOBTvIVSqq5FwEnlkX6aBXsg6IxKtbiT4cC9fpCeuZP4Pa 0QDhOQMjnvd8vrpFFschiKqbVfCx4ldj9We/LGbWrFUZ+Ir2mBlbhAggwldAbACN/BCVYX pp8dnbZbIw0pkRhn4wzqUCoFNjvAoBeaJegHoJN/JgNyIkQ1lYl19MUTvT02Ecz9UDlG4l MlqfrzPw8n9PoU3e9C9Yjny1M5NoEnesiFxLQUaKqiSQVA8oy2WD4Bai2b6KrJxD16ufLW dQb4pWjeeNcY58dCxJOwf/ETisiFLVe3vBEXbnzUXiLoQhRkRNLem3tqSScy7Q== Date: Tue, 26 Mar 2024 14:08:22 +0100 From: "Pankaj Raghav (Samsung)" To: Matthew Wilcox Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, gost.dev@samsung.com, chandan.babu@oracle.com, hare@suse.de, mcgrof@kernel.org, djwong@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@fromorbit.com, akpm@linux-foundation.org, Pankaj Raghav Subject: Re: [PATCH v3 05/11] readahead: allocate folios with mapping_min_order in readahead Message-ID: References: <20240313170253.2324812-1-kernel@pankajraghav.com> <20240313170253.2324812-6-kernel@pankajraghav.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8E2B7A0028 X-Stat-Signature: 961hm7z1kii1b9jwi5mrb5airbxyaqcs X-HE-Tag: 1711458511-912517 X-HE-Meta: U2FsdGVkX1+yPFlOtQQ/eAA+VKWrI27rD8Qcv4Ipy1J04S+edxPkUPGbqOqh7DjBX8keKROYLr62TBCC+x1z7onC7EOvZN/6x+fEPG84ookTRJYOOAiJT6tiO09DmW5RNcC1VJGY6/V5/7Q8NW1soRdlTgWn4akZ7IP7BQ+j7U8iTme1Dahqf0aOKCDDoGyYfa8bJG5ggO9pIwzoqUhJ7wjHJpu3Fo2QcO5Q46D+e8VwBDw6TP4FPdJTe+7Qc5zo1/Z7TE4HWVa8/0WoB2yQFOYEcWbbUYX1cVDMp9/2345NKydibOMSSCsajffaGUNhOQYotykWXF415yAIMjB7LGCITXPTArCqtJ7FsH4nXpLKBEAHDm6AmyoW1BbAi8+e+ZARvbJnxU7H9mhDb+EvocGYqTrHjIuTynZ00oPt+bfx/pktsm5DbtKLI99Ka3kb4JNR/Mt0IBH9JKsxeNPLPTRw7AP8mZVxgAjFmJM8u22niZ9C8Zy4U0jETr7cKtPpUnFQT6sjaTzi3Mp8vQ/BAKmgCOD1GcYWr2iT2zljGnV/8AoBAJSc8NFK6rFLH9xOumSPY6R+Ae92bIs3rHtKpGXVqNeh5qi4XNvVq7tR2cieRfV1P0QREgSz0fvckQm1bUJ2ASkl6uER1sNIdVMxpQPVF3fnGnpHqNn2tLc0E9E6HVS1X5o3jgLzpBVAdUjlVQVnoOuAnzuIWmGfu5Qp7PXGGX1fuHtUFw2YXFFtH60zeopEShDJKjLwmlcx5S1obDX2riGYmVvQ5iEUJDZr7i8VD7aUOy4iiyI3uU6IGisAnhhoDHAfvCu9R6pXtR7h5//sT1OJXnu8DCQDdbrfgVG8QhXVrJnxrYltMW1s+xjZPeuWYfdIkrq6APXVcVIp3oVwMC8NfB4ZC8/r17gBYKG2iK+RVHkOeu0gv2lwJT1KumvjWZtEqVfRzL2DdSxj1mQ9Op2sNoAphkFi2YQ B2NzRIOi UKLXhoEtIbxr6/nuUVbH+4F+ZgwcS8HnGaxSSJQug4VA0vfQg6XTkg38iEFmKsaxZb27r/UyhxISdn+B4caeU/yqScRmBOhjI97qz6p8UpNp9rdFI1VTWpDR/5D96X2P47ybrurT3DIhtx0TOWgBDDIdRVreb/i0fWxOYNMZ0d+LHOPPgRZL+zkbXDw9fBN3rms+ZOVvBepzrSqEcszHw/PUmD3vv8r8oFrP2Z1MD4xFah30LMyp2ASutgYSooxj09SK8c2/x5LLok3vDYOtfAY7ilw== 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: List-Subscribe: List-Unsubscribe: > > > > page_cache_ra_unbounded() was allocating single pages (0 order folios) > > if there was no folio found in an index. Allocate mapping_min_order folios > > as we need to guarantee the minimum order if it is set. > > When read_pages() is triggered and if a page is already present, check > > for truncation and move the ractl->_index by mapping_min_nrpages if that > > folio was truncated. This is done to ensure we keep the alignment > > requirement while adding a folio to the page cache. > > > > page_cache_ra_order() tries to allocate folio to the page cache with a > > higher order if the index aligns with that order. Modify it so that the > > order does not go below the min_order requirement of the page cache. > > This paragraph doesn't make sense. We have an assertion that there's no > folio in the page cache with a lower order than the minimum, so this > seems to be describing a situation that can't happen. Does it need to > be rephrased (because you're actually describing something else) or is > it just stale? > Hmm, maybe I need to explain better here. > > @@ -489,12 +520,18 @@ void page_cache_ra_order(struct readahead_control *ractl, > > { > > struct address_space *mapping = ractl->mapping; > > pgoff_t index = readahead_index(ractl); > > + unsigned int min_order = mapping_min_folio_order(mapping); > > pgoff_t limit = (i_size_read(mapping->host) - 1) >> PAGE_SHIFT; > > pgoff_t mark = index + ra->size - ra->async_size; > > int err = 0; > > gfp_t gfp = readahead_gfp_mask(mapping); > > + unsigned int min_ra_size = max(4, mapping_min_folio_nrpages(mapping)); > > > > - if (!mapping_large_folio_support(mapping) || ra->size < 4) I had one question: `4` was used here because we could not support order 1 folios I assume? As we now support order-1 folios, can this fallback if ra->size < min_nrpages? > > + /* > > + * Fallback when size < min_nrpages as each folio should be > > + * at least min_nrpages anyway. > > + */ > > + if (!mapping_large_folio_support(mapping) || ra->size < min_ra_size) > > goto fallback; > > > > limit = min(limit, index + ra->size - 1); > > @@ -505,9 +542,19 @@ void page_cache_ra_order(struct readahead_control *ractl, > > new_order = MAX_PAGECACHE_ORDER; > > while ((1 << new_order) > ra->size) > > new_order--; > > + if (new_order < min_order) > > + new_order = min_order; > > I think these are the two lines you're describing in the paragraph that Yes. At least I tried to ;) > doesn't make sense to me? And if so, I think they're useless? We need this because: The caller might pass new_order = 0 (such as when we start mmap around) but ra_order will do the "right" thing by taking care of the page cache alignment requirements. The previous revision did this other way around and it felt a bit all over the place. One of the main changes I did for this revision is to adapt the functions that alloc and add a folio to respect the min order alignment, and not on the caller side. The rationale I went for this is three fold: - the callers of page_cache_ra_order() and page_cache_ra_unbounded() requests a range for which we need to do add a folio and read it. They don't care about the folios size and alignment. - file_ra_state also does not need any poking around because we will make sure to cover from [ra->start, ra->size] and update ra->size if we spilled over due to the min_order requirement(like it was done before). - And this is also consistent with what we do in filemap where we adjust the index before adding the folio to the page cache. Let me know if this approach makes sense. > > > @@ -515,7 +562,7 @@ void page_cache_ra_order(struct readahead_control *ractl, > > if (index & ((1UL << order) - 1)) > > order = __ffs(index); > > /* Don't allocate pages past EOF */ > > - while (index + (1UL << order) - 1 > limit) > > + while (order > min_order && index + (1UL << order) - 1 > limit) > > order--; > > This raises an interesting question that I don't know if we have a test > for. POSIX says that if we mmap, let's say, the first 16kB of a 10kB > file, then we can store into offset 0-12287, but stores to offsets > 12288-16383 get a signal (I forget if it's SEGV or BUS). Thus far, > we've declined to even create folios in the page cache that would let us > create PTEs for offset 12288-16383, so I haven't paid too much attention > to this. Now we're going to have folios that extend into that range, so > we need to be sure that when we mmap(), we only create PTEs that go as > far as 12287. > > Can you check that we have such an fstest, and that we still pass it > with your patches applied and a suitably large block size? Hmmm, good point. I think you mean this from the man page: SIGBUS Attempted access to a page of the buffer that lies beyond the end of the mapped file. For an explanation of the treatment of the bytes in the page that corresponds to the end of a mapped file that is not a multiple of the page size, see NOTES. I will add a test case for this and see what happens. I am not sure if I need to make some changes or the current implementation should hold.