[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6d6b3bad.5f72.19bd535bd6d.Coremail.nzzhao@126.com>
Date: Mon, 19 Jan 2026 15:43:47 +0800 (CST)
From: "Nanzhe Zhao" <nzzhao@....com>
To: "Chao Yu" <chao@...nel.org>
Cc: jaegeuk@...nel.org, linux-kernel@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net
Subject: Re:Re: [f2fs-dev] [PATCH] f2fs: avoid f2fs_map_blocks() for
consecutive holes in readpages
Hi Chao:
At 2026-01-16 16:52:02, "Chao Yu" <chao@...nel.org> wrote:
>>
>> Do we have plans to also support reducing f2fs_map_blocks() calls for
>> consectives holes in logical file postion with dnode have already been
>> allocated in buffered large folio read?
>> Such as consective NULL_ADDR or NEW_ADDR?
>
>Nanzhe,
>
>We have supported that for large folio read w/ this patch?
>
>Thanks,
>
Sorry, I'm a bit confused.
In the condition of F2FS_MAP_BLOCK_DEFAULT, the default: case will only
set map->m_next_pgofs to pgofs + 1 then sync out. When we enter
next iteration and the index advanced, currrent index now turns to pgofs + 1
and index < next_pgofs become false.In consequence, we won't reduce
f2fs_map_blocks() calls for hole with dnode allocated.
Also, for NEW_ADDR, the default: case will directly go to sync out and bypass
map_is_mergeable, so it will also not reduce f2fs_map_blocks calls.
Or am I missing something?
Thanks,
Nanzhe Zhao
Powered by blists - more mailing lists