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 X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF1F8C433E1 for ; Tue, 25 Aug 2020 05:48:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB0C62071E for ; Tue, 25 Aug 2020 05:48:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728913AbgHYFsf (ORCPT ); Tue, 25 Aug 2020 01:48:35 -0400 Received: from mx2.suse.de ([195.135.220.15]:50594 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728861AbgHYFsf (ORCPT ); Tue, 25 Aug 2020 01:48:35 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5C5C9ACCF for ; Tue, 25 Aug 2020 05:49:04 +0000 (UTC) From: Qu Wenruo To: linux-btrfs@vger.kernel.org Subject: [PATCH v3 4/4] btrfs: avoid allocating unnecessary page pointers Date: Tue, 25 Aug 2020 13:48:08 +0800 Message-Id: <20200825054808.16241-5-wqu@suse.com> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200825054808.16241-1-wqu@suse.com> References: <20200825054808.16241-1-wqu@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Commit 142349f541d0 ("btrfs: lower the dirty balance poll interval") introduced one limit which is definitely suspicious: - ensure we always have 8 pages allocated The 8 lower limit looks pretty strange, this means even we're just writing 4K, we will allocate page pointers for 8 pages no matter what. To me, this 8 pages look more like a upper limit. This 8 pages upper limit looks so incorrect that my eyes alawys correct it into "min(, 8)" other than "max(, 8)". This patch will use a fixed size (SZ_64K) other than page numbers to setup the upper limit. Also, with comment added to show why we need a upper limit. Signed-off-by: Qu Wenruo --- fs/btrfs/file.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 67d2368a8fa6..de6d1c313042 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1561,7 +1561,14 @@ static int calc_nr_pages(loff_t pos, struct iov_iter *iov) nr_pages = min(nr_pages, current->nr_dirtied_pause - current->nr_dirtied); - nr_pages = max(nr_pages, 8); + + /* + * Limit the batch to 64K, too large batch may lead to higher memory + * pressure and increase the possibility of short-copy. + * With more and more short-copy, the benefit of batch copy would be + * hugely reduced, as we will fall back to page-by-page copy. + */ + nr_pages = min(nr_pages, SZ_64K / PAGE_SIZE); return nr_pages; } -- 2.28.0