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 08CACC3ABB6 for ; Mon, 5 May 2025 09:53:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 441E56B008A; Mon, 5 May 2025 05:53:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EF766B008C; Mon, 5 May 2025 05:53:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E1076B0092; Mon, 5 May 2025 05:53:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 11A986B008A for ; Mon, 5 May 2025 05:53:03 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BF3DD1A1E34 for ; Mon, 5 May 2025 09:53:03 +0000 (UTC) X-FDA: 83408390646.01.7CFF61A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf06.hostedemail.com (Postfix) with ESMTP id 7CB36180006 for ; Mon, 5 May 2025 09:53:01 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="o8okGg/+"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=4S5rgwGK; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="o8okGg/+"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=4S5rgwGK; dmarc=none; spf=pass (imf06.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746438781; 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=utEcYmPzi75tBBr1KPTD9Ao4NpHZqIdSmjTjxwEplbw=; b=LsJubfyO5i5hLOZI0bo1W+CBmbnVoeH6IPBzxFLCA+cUY3MZVmzC0KVZlBdGfytXzptiWa A1pnTDG2sBdtiaKwy7koiA2IZJ1kif7yDUiZ6e8dKGYKQqHfJzM++3TpOG/P/7FrLruxBW g3sdYHen/MjjEmDoS8htXDO9ENGgDoA= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="o8okGg/+"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=4S5rgwGK; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="o8okGg/+"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=4S5rgwGK; dmarc=none; spf=pass (imf06.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746438781; a=rsa-sha256; cv=none; b=x+uVTfAZG7VwJiqj2nTVTfBdEZhIuvsSpavgCQkxy7MIhl8rmIKVAHAcf3J3I9B6ZgWqmT dC9umoZqtlW+2T/TzAND7IZD5Y+Bp5U+JaODf/z5BYJcC/JSSJ6BKWf7SCvdQnHWwj9Cfi VsfYcbCJdTcVKrmdf8qLTzMT9LbfEaM= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (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 smtp-out1.suse.de (Postfix) with ESMTPS id A797921284; Mon, 5 May 2025 09:52:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1746438779; h=from:from:reply-to: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=utEcYmPzi75tBBr1KPTD9Ao4NpHZqIdSmjTjxwEplbw=; b=o8okGg/+K3DCf5QTCTgixqzxYorI5hidAenUdxMQbnDCNtHUgy8r/ACuLvIGe1sb03HfZh zC6Hw2zzPr4X9XIR328qCUUznNVDjD7O8hT7DYcmqR3lWoRvd0xuh6teQuLyIUgruYIJNJ kA+bHdYTgLzzf2qVSDSodR20pNtGNNs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1746438779; h=from:from:reply-to: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=utEcYmPzi75tBBr1KPTD9Ao4NpHZqIdSmjTjxwEplbw=; b=4S5rgwGKNxA3QOK7Vy+0cJvPP0kfdam9XhEFGYx3+SjKnw9GScOHiiVALf5mzxWRbLeSip bU/JhR5mHqu/aJCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1746438779; h=from:from:reply-to: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=utEcYmPzi75tBBr1KPTD9Ao4NpHZqIdSmjTjxwEplbw=; b=o8okGg/+K3DCf5QTCTgixqzxYorI5hidAenUdxMQbnDCNtHUgy8r/ACuLvIGe1sb03HfZh zC6Hw2zzPr4X9XIR328qCUUznNVDjD7O8hT7DYcmqR3lWoRvd0xuh6teQuLyIUgruYIJNJ kA+bHdYTgLzzf2qVSDSodR20pNtGNNs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1746438779; h=from:from:reply-to: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=utEcYmPzi75tBBr1KPTD9Ao4NpHZqIdSmjTjxwEplbw=; b=4S5rgwGKNxA3QOK7Vy+0cJvPP0kfdam9XhEFGYx3+SjKnw9GScOHiiVALf5mzxWRbLeSip bU/JhR5mHqu/aJCw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (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 imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 92FDF13883; Mon, 5 May 2025 09:52:59 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 9kzfI3uKGGjPcwAAD6G6ig (envelope-from ); Mon, 05 May 2025 09:52:59 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 5668AA0670; Mon, 5 May 2025 11:52:55 +0200 (CEST) Date: Mon, 5 May 2025 11:52:55 +0200 From: Jan Kara To: Ryan Roberts Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , Alexander Viro , Christian Brauner , Jan Kara , David Hildenbrand , Dave Chinner , Catalin Marinas , Will Deacon , Kalesh Singh , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v4 4/5] mm/readahead: Store folio order in struct file_ra_state Message-ID: References: <20250430145920.3748738-1-ryan.roberts@arm.com> <20250430145920.3748738-5-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250430145920.3748738-5-ryan.roberts@arm.com> X-Rspamd-Action: no action X-Stat-Signature: 53mcaciwb88gfw1cshtyg34f9ak8bd6z X-Rspamd-Queue-Id: 7CB36180006 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1746438781-426657 X-HE-Meta: U2FsdGVkX18j2pAmViE56bW6BW+jz2DWVQLHX+I2r21fyqOcRCQG/hi+J6gLmzNZLYcB/XJbWY60mmFDXo2Mvf/9ejwyGPf3A+7ayPJQXAtexoajYTliUYaXAqQ3ImKHZTvJmkEycrO7/IPHIp9jZJuDWsQe83xG5N5xdmj1i+AEvDZA44cEgEityEj5/e9sOa0GxEwPtI1DVoUQObxATO3mI2tTUS9W1rzKupEHBAQFx+MopDhlzkDKp/+rFckx4dVFisX2++jTaGcLVgpjC2J7al69HzqXlY6GlxZLJWxeg4LtlTXZppzECd5fp8Qk0YyTLTkMUiFGcuCh3Wl2AMYLQbCn7hNzRBN7d2975I1J27Powy8PkBHfnMOeyuVVVHnUSFkMdhqDaeIOpTnw1pMwdi7kZhDHCYsQqSM8VytDN/ak/v9BvZcQXjWylfUrynudOgnq9aLIb2325cNIbQn1Thg0MNTNxdoLctS95Ukadw8VqFdu/Pp1lJ++RbEYkGCnrnhJD9aUSQ1+GLZYMZy55ZhYZ5sK1XCz8V6JiSgPyyELmSILBo5xya7QLhcGCu0K7lqBOJZRWpmxTXbr21fbjtf0p5Xm3pqBKYkEbL63XXTGcURF7QdUZKFkaqN0hd/648r2gIsYiR0CcG5dXhAynZmw/gFVQpSLiPttHJa+WCRZFGVHvaZibkecmR0fzUTgcmK1fIEe+UBFt4UyEfENcNY/jlw4Ggw3g9ZF7s5rgsAII+bpOwiYltMnhoPwJaNFMLRhEkPOSch9Hy1WsUY8Ym9yMeLKi9chpwpfYNTzLWc+G8F+C9vYzu3rr2VbAAEyFB734989bAMspQ+rG83hlABUESi9kCFVA46YapZIA2tyRzxMoSwX9Jv4t/uTbhf84SZRVEju4/ke78BEl9esriQoYjpZjMiGK1MMh7UPV/LnKJ9rkXCr0WrHie0iR1x6cNfbZIFu8wYHbbj WfxXmvZn lqzEY 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: On Wed 30-04-25 15:59:17, Ryan Roberts wrote: > Previously the folio order of the previous readahead request was > inferred from the folio who's readahead marker was hit. But due to the > way we have to round to non-natural boundaries sometimes, this first > folio in the readahead block is often smaller than the preferred order > for that request. This means that for cases where the initial sync > readahead is poorly aligned, the folio order will ramp up much more > slowly. > > So instead, let's store the order in struct file_ra_state so we are not > affected by any required alignment. We previously made enough room in > the struct for a 16 order field. This should be plenty big enough since > we are limited to MAX_PAGECACHE_ORDER anyway, which is certainly never > larger than ~20. > > Since we now pass order in struct file_ra_state, page_cache_ra_order() > no longer needs it's new_order parameter, so let's remove that. > > Worked example: > > Here we are touching pages 17-256 sequentially just as we did in the > previous commit, but now that we are remembering the preferred order > explicitly, we no longer have the slow ramp up problem. Note > specifically that we no longer have 2 rounds (2x ~128K) of order-2 > folios: > > TYPE STARTOFFS ENDOFFS SIZE STARTPG ENDPG NRPG ORDER RA > ----- ---------- ---------- ---------- ------- ------- ----- ----- -- > HOLE 0x00000000 0x00001000 4096 0 1 1 > FOLIO 0x00001000 0x00002000 4096 1 2 1 0 > FOLIO 0x00002000 0x00003000 4096 2 3 1 0 > FOLIO 0x00003000 0x00004000 4096 3 4 1 0 > FOLIO 0x00004000 0x00005000 4096 4 5 1 0 > FOLIO 0x00005000 0x00006000 4096 5 6 1 0 > FOLIO 0x00006000 0x00007000 4096 6 7 1 0 > FOLIO 0x00007000 0x00008000 4096 7 8 1 0 > FOLIO 0x00008000 0x00009000 4096 8 9 1 0 > FOLIO 0x00009000 0x0000a000 4096 9 10 1 0 > FOLIO 0x0000a000 0x0000b000 4096 10 11 1 0 > FOLIO 0x0000b000 0x0000c000 4096 11 12 1 0 > FOLIO 0x0000c000 0x0000d000 4096 12 13 1 0 > FOLIO 0x0000d000 0x0000e000 4096 13 14 1 0 > FOLIO 0x0000e000 0x0000f000 4096 14 15 1 0 > FOLIO 0x0000f000 0x00010000 4096 15 16 1 0 > FOLIO 0x00010000 0x00011000 4096 16 17 1 0 > FOLIO 0x00011000 0x00012000 4096 17 18 1 0 > FOLIO 0x00012000 0x00013000 4096 18 19 1 0 > FOLIO 0x00013000 0x00014000 4096 19 20 1 0 > FOLIO 0x00014000 0x00015000 4096 20 21 1 0 > FOLIO 0x00015000 0x00016000 4096 21 22 1 0 > FOLIO 0x00016000 0x00017000 4096 22 23 1 0 > FOLIO 0x00017000 0x00018000 4096 23 24 1 0 > FOLIO 0x00018000 0x00019000 4096 24 25 1 0 > FOLIO 0x00019000 0x0001a000 4096 25 26 1 0 > FOLIO 0x0001a000 0x0001b000 4096 26 27 1 0 > FOLIO 0x0001b000 0x0001c000 4096 27 28 1 0 > FOLIO 0x0001c000 0x0001d000 4096 28 29 1 0 > FOLIO 0x0001d000 0x0001e000 4096 29 30 1 0 > FOLIO 0x0001e000 0x0001f000 4096 30 31 1 0 > FOLIO 0x0001f000 0x00020000 4096 31 32 1 0 > FOLIO 0x00020000 0x00021000 4096 32 33 1 0 > FOLIO 0x00021000 0x00022000 4096 33 34 1 0 > FOLIO 0x00022000 0x00024000 8192 34 36 2 1 > FOLIO 0x00024000 0x00028000 16384 36 40 4 2 > FOLIO 0x00028000 0x0002c000 16384 40 44 4 2 > FOLIO 0x0002c000 0x00030000 16384 44 48 4 2 > FOLIO 0x00030000 0x00034000 16384 48 52 4 2 > FOLIO 0x00034000 0x00038000 16384 52 56 4 2 > FOLIO 0x00038000 0x0003c000 16384 56 60 4 2 > FOLIO 0x0003c000 0x00040000 16384 60 64 4 2 > FOLIO 0x00040000 0x00050000 65536 64 80 16 4 > FOLIO 0x00050000 0x00060000 65536 80 96 16 4 > FOLIO 0x00060000 0x00080000 131072 96 128 32 5 > FOLIO 0x00080000 0x000a0000 131072 128 160 32 5 > FOLIO 0x000a0000 0x000c0000 131072 160 192 32 5 > FOLIO 0x000c0000 0x000e0000 131072 192 224 32 5 > FOLIO 0x000e0000 0x00100000 131072 224 256 32 5 > FOLIO 0x00100000 0x00120000 131072 256 288 32 5 > FOLIO 0x00120000 0x00140000 131072 288 320 32 5 Y > HOLE 0x00140000 0x00800000 7077888 320 2048 1728 > > Signed-off-by: Ryan Roberts ... > @@ -469,6 +469,7 @@ void page_cache_ra_order(struct readahead_control *ractl, > int err = 0; > gfp_t gfp = readahead_gfp_mask(mapping); > unsigned int min_ra_size = max(4, mapping_min_folio_nrpages(mapping)); > + unsigned int new_order = ra->order; > > /* > * Fallback when size < min_nrpages as each folio should be > @@ -483,6 +484,8 @@ void page_cache_ra_order(struct readahead_control *ractl, > new_order = min_t(unsigned int, new_order, ilog2(ra->size)); > new_order = max(new_order, min_order); > > + ra->order = new_order; > + > /* See comment in page_cache_ra_unbounded() */ > nofs = memalloc_nofs_save(); > filemap_invalidate_lock_shared(mapping); > @@ -525,6 +528,7 @@ void page_cache_ra_order(struct readahead_control *ractl, > * ->readahead() may have updated readahead window size so we have to > * check there's still something to read. > */ > + ra->order = 0; Hum, so you reset desired folio order if readahead hit some pre-existing pages in the page cache. Is this really desirable? Why not leave the desired order as it was for the next request? > if (ra->size > index - start) > do_page_cache_ra(ractl, ra->size - (index - start), > ra->async_size); Honza -- Jan Kara SUSE Labs, CR