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 11108C25B7C for ; Fri, 24 May 2024 12:18:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 773F06B0083; Fri, 24 May 2024 08:18:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 724556B0088; Fri, 24 May 2024 08:18:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 613446B0089; Fri, 24 May 2024 08:18:42 -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 45DEA6B0083 for ; Fri, 24 May 2024 08:18:42 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0243D160352 for ; Fri, 24 May 2024 12:18:41 +0000 (UTC) X-FDA: 82153192884.14.5BC489A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 8420B40023 for ; Fri, 24 May 2024 12:18:40 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=lepPuE9q; dmarc=none; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716553120; 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=vbEsMDh+E9GqojdWiKM6c4copHUEF+ZhaKXyW3Xhetg=; b=27mXaKaYL3Vacu0QwRsr6bAc1VmUTS7tdZ3ImttJd7sr01AqK6fXebypQ9WBj4va7R/BI7 Z7h9CIL2X0EGb7qBDIzEMOiU+sU3Hdmegi6OYuDJmWaW2eirB3cCAJ8NmV8oXKNYc0jIPz b49CNZughFc0kjQJDC/yLY4kHm7bR4w= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=lepPuE9q; dmarc=none; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716553120; a=rsa-sha256; cv=none; b=xNcmj7q6n0WpYGi5ZCiaCSG2JIAPQydfl45bL/9OGPlNBwwjGZnr+Wf7ZTxQQVT2s0MATs ziNCsfOWZCeXioY5VJJM0h0+XxTTeLU72QQRyUUC1/mVT6gGWN7E3aeUS8GyvA8a6XEep8 NCtwYvda4h+8nn7a+Y4B5j3R75+qkRQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vbEsMDh+E9GqojdWiKM6c4copHUEF+ZhaKXyW3Xhetg=; b=lepPuE9qDtPJho7Qxv+ml69iYD wqnNO1/3aCN7fNuLsBd8G0XhyWdw4M2ziQxVY5tnpCy2WZKPGpDleB/ZH19zsCAVu8t+zSv5oYHoi wS/D2d1niHKRzC1x8CIdC1V99uG9jWbAoGVrMDRCIuBJA3W+qyDKmcpLA/eKI4JV94hQGdH8BQEwl KkID2EDDDMlVWh40oHOZBw0NHzL14zga0Bfcy1iYkjcEQ5APE1K53L7MBN2+prAeu78BVaQyqNene urU4eZx4ZtLhE1Y6LJebQj+F+ZKBdOgQrM1opPychQlvObh07XyEdMfBmaYetiFOaYu0c4YavDAUh Q/AoXQUw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sATsc-00000002eqS-2EiW; Fri, 24 May 2024 12:18:38 +0000 Date: Fri, 24 May 2024 13:18:38 +0100 From: Matthew Wilcox To: Xu Yang Cc: brauner@kernel.org, djwong@kernel.org, akpm@linux-foundation.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, jun.li@nxp.com Subject: Re: [PATCH v5 2/2] iomap: fault in smaller chunks for non-large folio mappings Message-ID: References: <20240521114939.2541461-1-xu.yang_2@nxp.com> <20240521114939.2541461-2-xu.yang_2@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240521114939.2541461-2-xu.yang_2@nxp.com> X-Rspamd-Queue-Id: 8420B40023 X-Stat-Signature: 9515bsuub78ygzx8rxsgbxpjxkij911h X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1716553120-580470 X-HE-Meta: U2FsdGVkX19DCZL3gAXBkhRGWeScoUIUsiNd1t2rCLkW5qPSRQ2LsMa9E4v0mmj5cRlG8+ZLhKaMihIcxqeJVU2GPsdhSvyk5I6bR7i95mx/I6xId0DE9g1dihYsrE4hcsL4cDtPiSTZkZWjx0OGGZ4tb7GRMfUrKACwDey2a3Ywbqe+t/rsWPVCyZC8rEiytKkKltWSUefjhpSS2hOiAjVNCkTRN2djeEwDQMthl3p8B0yO3GVpMUfowFuAn6is215DpE9qSZrL41YLHM+99jbrwEaYtdBh0J4VqpC0Il1m7MeRyLwW9s7m/ttUcjb+vVhY0zeuAnS6ihFPmSN0QigxOIWVqptYinBYvglbwT5WZWpJBAcZ3pKIPkusUvk7Mbqdh4ZustGpOxvn2dtvZLWpc1MHLCO0xZL2QqgE93AnqUehb2ua25nh1ge/4nhgEVaxeAE/LPi0ELveM7zBWuuFmEI47rPYmuPUUUG3qaTSO8D+g1w1lVsDYYVXGSPGMFWgu4Md6qCfLabG4YuosZVNmWgF6yJy0CAsNZ0PsUFrw4Wrh7RaY3HFkmGRpR5+hFe/B6M3HQmRtMR88wSAdeRgQwgeoz6RYBQj9Wh5GL0xTal4V5aTIBmMKgMV38FLvrMT+bWZNt8XtoubYM9cU3o4qRj+r7CZXiwMgXqG4ux/q7Enr3n0aQoUxEMlb0rMrSARCWMQs3feT1dOPiIB61BHihKs4wXVdScg8inYJu9/BbRCqp22lXi2itsrubB5tcUsUi+diGczhAH4tYKtu3OsmD39bpTEkk12jBVbqIXOD5H9z0VIt8GRnrFeTTIqamCZeyNRb08EIcAmmRQhDA== 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 Tue, May 21, 2024 at 07:49:39PM +0800, Xu Yang wrote: > Since commit (5d8edfb900d5 "iomap: Copy larger chunks from userspace"), > iomap will try to copy in larger chunks than PAGE_SIZE. However, if the > mapping doesn't support large folio, only one page of maximum 4KB will > be created and 4KB data will be writen to pagecache each time. Then, > next 4KB will be handled in next iteration. This will cause potential > write performance problem. > > If chunk is 2MB, total 512 pages need to be handled finally. During this > period, fault_in_iov_iter_readable() is called to check iov_iter readable > validity. Since only 4KB will be handled each time, below address space > will be checked over and over again: > > start end > - > buf, buf+2MB > buf+4KB, buf+2MB > buf+8KB, buf+2MB > ... > buf+2044KB buf+2MB > > Obviously the checking size is wrong since only 4KB will be handled each > time. So this will get a correct chunk to let iomap work well in non-large > folio case. > > With this change, the write speed will be stable. Tested on ARM64 device. > > Before: > > - dd if=/dev/zero of=/dev/sda bs=400K count=10485 (334 MB/s) > - dd if=/dev/zero of=/dev/sda bs=800K count=5242 (278 MB/s) > - dd if=/dev/zero of=/dev/sda bs=1600K count=2621 (204 MB/s) > - dd if=/dev/zero of=/dev/sda bs=2200K count=1906 (170 MB/s) > - dd if=/dev/zero of=/dev/sda bs=3000K count=1398 (150 MB/s) > - dd if=/dev/zero of=/dev/sda bs=4500K count=932 (139 MB/s) > > After: > > - dd if=/dev/zero of=/dev/sda bs=400K count=10485 (339 MB/s) > - dd if=/dev/zero of=/dev/sda bs=800K count=5242 (330 MB/s) > - dd if=/dev/zero of=/dev/sda bs=1600K count=2621 (332 MB/s) > - dd if=/dev/zero of=/dev/sda bs=2200K count=1906 (333 MB/s) > - dd if=/dev/zero of=/dev/sda bs=3000K count=1398 (333 MB/s) > - dd if=/dev/zero of=/dev/sda bs=4500K count=932 (333 MB/s) > > Fixes: 5d8edfb900d5 ("iomap: Copy larger chunks from userspace") > Cc: stable@vger.kernel.org > Reviewed-by: Darrick J. Wong > Signed-off-by: Xu Yang Reviewed-by: Matthew Wilcox (Oracle)