From nobody Sun Oct 5 23:50:35 2025 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 711C617A2F8; Mon, 28 Jul 2025 08:40:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753692032; cv=none; b=q7LuxZiQ1j4LNguzxZBCrb8Hw8Kajf6kUH7N8wGONCNMxs1yTcwNefgA2FYxgMKA6/pLJD2VKMmmo+ztLD39jQSa+FHlOV3Iq2rsgBpFLtjrgZ1ffRQTG/BVcY2O6DNnfioh6hiE3+qhqAxOb8PqnoLmyit2F7Qo1+HXJPZglX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753692032; c=relaxed/simple; bh=8KKXNW143k0p91dd9ZHSDzkjOdRShAfQ3unzS2b1pOc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p/LNcW3GIzQ+cLTLrLan8ugzsP9u+UDm3g1Prh+iSqPitb1qj8ZYP47kA8gAn8LQ+InJxVRc6upDsCgQs0J1/H0a5FQNuaLdr9rPD4u909moeVJBDcDhLexM4xhJfqLQU9SZteXFj54TlSIAIXaECcpJvzCytd4ttRX5UIo1qFc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=avRDumut; arc=none smtp.client-ip=117.135.210.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="avRDumut" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=f/ UKDMw0joXHfqIOWrWMvMtfuY+C4akEWZAyWYlG4oc=; b=avRDumutFFV7+/xhP7 lAv3mT4OTjWtezxFpYrmQJGArckPgmn+iy4Mo49wDJSbVrMnCuOlmccX3dK+vb/L gYXpNEcfZLPuCGqHKuaiEedsDpCdn1dhaNCcuAONs4UxYY9lDxhIPBjCGRn8tcy1 5f3Yf8UaP+pM5zRjqclK2AwCw= Received: from czl-ubuntu-pc.. (unknown []) by gzsmtp2 (Coremail) with SMTP id PSgvCgAH9a9hN4doAzUWCQ--.8415S3; Mon, 28 Jul 2025 16:40:03 +0800 (CST) From: Chi Zhiling To: willy@infradead.org, akpm@linux-foundation.org Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chi Zhiling Subject: [PATCH v1 1/2] mm/filemap: Do not use is_partially_uptodate for entire folio Date: Mon, 28 Jul 2025 16:39:51 +0800 Message-ID: <20250728083952.75518-2-chizhiling@163.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250728083952.75518-1-chizhiling@163.com> References: <20250728083952.75518-1-chizhiling@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: PSgvCgAH9a9hN4doAzUWCQ--.8415S3 X-Coremail-Antispam: 1Uf129KBjvdXoWrZr4xXw1DGFyUtFy8GFWruFg_yoWftFg_Wr W8Zw4kGa9xCF9xAr4IvF4DJr90qw1v9rWFvFZ0qF43A345A34kZFWqvF92gr47Jr4FkFs8 JwsFgr15Zr13ujkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IU8EtC7UUUUU== X-CM-SenderInfo: hfkl6xxlol0wi6rwjhhfrp/1tbiFBSUnWiBj9Y5uAACs6 Content-Type: text/plain; charset="utf-8" From: Chi Zhiling When a folio is marked as non-uptodate, it means the folio contains some non-uptodate data. Therefore, calling is_partially_uptodate() to recheck the entire folio is redundant. If all data in a folio is actually up-to-date but the folio lacks the uptodate flag, it will still be treated as non-uptodate in many other places. Thus, there should be no special case handling for filemap. Signed-off-by: Chi Zhiling --- mm/filemap.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/filemap.c b/mm/filemap.c index 0e103fc99a8e..00c30f7f7dc3 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2447,6 +2447,9 @@ static bool filemap_range_uptodate(struct address_spa= ce *mapping, pos -=3D folio_pos(folio); } =20 + if (pos =3D=3D 0 && count >=3D folio_size(folio)) + return false; + return mapping->a_ops->is_partially_uptodate(folio, pos, count); } =20 --=20 2.43.0 From nobody Sun Oct 5 23:50:35 2025 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.2]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C91DE2AE68; Mon, 28 Jul 2025 08:40:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753692030; cv=none; b=I9U+8K3bmA7flyAuo6vAkeEqhXOWC7cOpLQ0bEA3rQT9nrddkBqSLJB4q0D/QBhA16dhxP64esfyXrQExP6TMRoBJrrvzhHzmturkHNzMFqvVzuSL9oi1EqUuKzfChj6CUDvRCM/eQ/0fq/krCxSEWAFZkFXLtnZ3fJlCk7/aHk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753692030; c=relaxed/simple; bh=8HXJmQ/04NJvw6kus97NYmIgyj/MJ6DycDjPq7oVA2E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kb6mHmOViecyUxjpwZ4EjiuoHusFyA9k+5cPiwesto+ZxhQZXCdgltuK/7U7sWVJvFXSXSIP3ZbJyo2wk7+0UtTs95ikV6qyrbEJJkRSf3Vhx0qxFJEcmeNxJe2t01OfV90lm8hHmClXJwEJkhc57oBTjASFUaGd2Yl5A24Crrk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=S8+76Hp8; arc=none smtp.client-ip=117.135.210.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="S8+76Hp8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=zk iIDNJ189UN3Gvigro6HmhFmr3/xqt0rx4GudPl97g=; b=S8+76Hp8/WS9fIVESB XjqzjYH3q5dvVgttmr85KXXmZkxQv/Fc7tP6X/PEQclJaJW1leuYolTz4fzc3QGh I9O54yDiJP9u6z0xuvBlBMMBl+L556ix+mYS6KtqPknJ2qUUuZGHKNtKc6OY80u0 FY1gdO3Ye056LnWIzNN/offTU= Received: from czl-ubuntu-pc.. (unknown []) by gzsmtp2 (Coremail) with SMTP id PSgvCgAH9a9hN4doAzUWCQ--.8415S4; Mon, 28 Jul 2025 16:40:03 +0800 (CST) From: Chi Zhiling To: willy@infradead.org, akpm@linux-foundation.org Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chi Zhiling Subject: [PATCH v1 2/2] mm/filemap: Skip non-uptodate folio if there are available folios Date: Mon, 28 Jul 2025 16:39:52 +0800 Message-ID: <20250728083952.75518-3-chizhiling@163.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250728083952.75518-1-chizhiling@163.com> References: <20250728083952.75518-1-chizhiling@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: PSgvCgAH9a9hN4doAzUWCQ--.8415S4 X-Coremail-Antispam: 1Uf129KBjvJXoW7tFy8WrWDCry7uw4fZry3twb_yoW8Zw1kpF WagwnF93srXFy8Can7AwnruF4Ig39Yyay5Gry5KF95Awn8X3sa9ryIvF15t3W7AryrZr1I qr1Fy340vanYv3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jDtxfUUUUU= X-CM-SenderInfo: hfkl6xxlol0wi6rwjhhfrp/xtbBgBSYnWiHLinmMQAAsu Content-Type: text/plain; charset="utf-8" From: Chi Zhiling When reading data exceeding the maximum IO size, the operation is split into multiple IO requests, but the data isn't immediately copied to userspace after each 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 41 pages and issue read ahead for next 1280k 3. copy 31 pages to user buffer 4. wait the next 1280k 5. copy 8 pages to user buffer 6. copy 20 folios(64k) to user buffer The 8 pages in step 5 are copied after the second 1280k completes(step 4) due to waiting for a non-uptodate folio in filemap_update_page. We can copy the 8 pages before the second 1280k completes(step 4) to reduce the latency of this read operation. After applying the patch, these 8 pages will be copied before the next IO completes: 1. read 1280k 2. copy 41 pages and issue read ahead for next 1280k 3. copy 31 pages to user buffer 4. copy 8 pages to user buffer 5. wait the next 1280k 6. copy 20 folios(64k) to user buffer This patch drops a setting of IOCB_NOWAIT for AIO, which is fine because filemap_read will set it again for AIO. The final solution provided by Matthew Wilcox: Link: https://lore.kernel.org/linux-fsdevel/aIDy076Sxt544qja@casper.infrade= ad.org/ Suggested-by: Matthew Wilcox (Oracle) Signed-off-by: Chi Zhiling --- mm/filemap.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index 00c30f7f7dc3..d2e07184b281 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2623,9 +2623,10 @@ static int filemap_get_pages(struct kiocb *iocb, siz= e_t count, goto err; } if (!folio_test_uptodate(folio)) { - if ((iocb->ki_flags & IOCB_WAITQ) && - folio_batch_count(fbatch) > 1) - iocb->ki_flags |=3D IOCB_NOWAIT; + if (folio_batch_count(fbatch) > 1) { + err =3D -EAGAIN; + goto err; + } err =3D filemap_update_page(iocb, mapping, count, folio, need_uptodate); if (err) --=20 2.43.0