[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250723101825.607184-1-chizhiling@163.com>
Date: Wed, 23 Jul 2025 18:18:22 +0800
From: Chi Zhiling <chizhiling@....com>
To: akpm@...ux-foundation.org,
willy@...radead.org
Cc: linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
Chi Zhiling <chizhiling@...inos.cn>
Subject: [RFC PATCH 0/3] Tiny optimization for large read operations
From: Chi Zhiling <chizhiling@...inos.cn>
Fine-Tuned Optimization for Large IO Read Operations
When reading data exceeding the maximum IO size, the operation is split into multiple IO requests, but the data isn't immediately copied to user space after IO completion.
For example, when reading 2560k data from a device with 1280k maximum IO size, the following sequence occurs:
1. read 1280k
2. copy 31 pages to user buffer
3. copy 10 pages and issue read ahead for next 1280k
4. copy 31 pages to user buffer
5. wait the next 1280k
6. copy 8 pages to user buffer
7. copy 20 folios(64k) to user buffer
The 8 pages in step 6 are copied after the second 1280k completes due to waiting for non-uptodate folio in filemap_update_page.
After applying the patch, these 8 pages will be copied before the next IO completes:
1. read 1280k
2. copy 31 pages to user buffer
3. copy 10 pages and issue read ahead for next 1280k
4. copy 31 pages to user buffer
5. copy 8 pages to user buffer
6. wait the next 1280k
7. copy 20 folios(64k) to user buffer
Chi Zhiling (3):
mm/filemap: Do not use is_partially_uptodate for entire folio
mm/filemap: Avoid modifying iocb->ki_flags for AIO in
filemap_get_pages()
mm/filemap: Skip non-uptodate folio when folios are available
mm/filemap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
--
2.43.0
Powered by blists - more mailing lists