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 AAA55C77B70 for ; Mon, 17 Apr 2023 12:26:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 272D58E0003; Mon, 17 Apr 2023 08:26:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 223728E0001; Mon, 17 Apr 2023 08:26:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1127B8E0003; Mon, 17 Apr 2023 08:26:02 -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 02ED58E0001 for ; Mon, 17 Apr 2023 08:26:02 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BFD9CC0468 for ; Mon, 17 Apr 2023 12:26:01 +0000 (UTC) X-FDA: 80690804922.26.4DF5037 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id BE2FD40022 for ; Mon, 17 Apr 2023 12:25:58 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xyuo2hSy; 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; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681734360; a=rsa-sha256; cv=none; b=SDc9ZXMMVIHZPwPTPmgLDxb4ZAnsQTsQuI83kTYF4jug2R6bT5qnx2vKvRHgziTJAuLMUj /MIx9KdApGqMkaUEpvyrlkK7LT51IyvwoVJz69GT5hEdiF19lyRU9ZSH+IQlSns5BxYTPa icXxLTp9WVqz7Yn09jLlOfCtAXbNFI8= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Xyuo2hSy; 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; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681734360; 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=MPztqyrjZ4LFdWkF0LGZ+/3Crq2sdqYNdGWHttezRQU=; b=VblrXNrD5yeIzjbOTAgQE2sxtI8JJatsCyIxoFTCPp6TmjruPmd2jsdDY74jENuIJ8/zmm ja/7VBkcJ+tjTyqsivK9bBq2BuBOdCv6XUXokhpVQQ7demNavrjnW0hyi0p3WVqwNv+w3U ai5Fan1MYjILUJiRR9zIgnDfSeyGYvI= 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=MPztqyrjZ4LFdWkF0LGZ+/3Crq2sdqYNdGWHttezRQU=; b=Xyuo2hSyoOI08PmIJ6pqsgALKL SgJTWR5sPVDiAt4FhGo/5463lT5snVxKm25eUPAmfG2Cm6u4tW/rFIVW6F7V7pv27PhRv5nVNvBvV eHKGxIScO9TUIabRSX7t9ghwWhq5Cf6ane6v5RqyTYhgERx8KXoqsnYBBE+eFGga3PN+gHW2J0PF8 QdM64yv0TNWDEbi0ONHRixjA0Rn3bSvRc+LXmn2wgiRbiydu9rLT6luG9b0l6/mTQDpzwecXHjEZK UuLdiJm+1lRAgSNEs4FkgV+LoGY55MOSawwkWHc/rD8DyItdiHmnCZomN5gAAZxlMG1tRnlSwatNt +wvN2FKg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1poNvd-00BKUU-BL; Mon, 17 Apr 2023 12:25:53 +0000 Date: Mon, 17 Apr 2023 13:25:53 +0100 From: Matthew Wilcox To: Yin Fengwei Cc: linux-mm@kvack.org, akpm@linux-foundation.org, yuzhao@google.com, ryan.roberts@arm.com Subject: Re: [PATCH 2/2] lru: allow large batched add large folio to lru list Message-ID: References: <20230417075643.3287513-1-fengwei.yin@intel.com> <20230417075643.3287513-3-fengwei.yin@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230417075643.3287513-3-fengwei.yin@intel.com> X-Rspam-User: X-Rspamd-Queue-Id: BE2FD40022 X-Rspamd-Server: rspam01 X-Stat-Signature: ossjog59miobzogotgrw3thxpm96apbh X-HE-Tag: 1681734358-152941 X-HE-Meta: U2FsdGVkX197q8jv728NpOy0B/1hWAaX5pkC3XFVqRok46VHozuzuMvBRmEomqaD27xgo55gJzShqhNhLFMhJZAu6Fx6unOmmFCr1Co28K4/sAC6zxja72Hz2l0N4tB6jEEDwAtUm9ocmdvNYPyL7H94cW/nW3Vnw4/Dn2Bs00tvyctXZO+R7sqp1mrBm2E/L1S/79j7/RZFt4QNAumhfFHOfS99eY6PHTOJwSdjv8/12XBDazbyaKkZimvYYGjMx+jqX7ATAVCiX+0GOQdaDpaEmWyj9lMgZG6W3Y9KStvGwTXGEpLLa4eqxjo6iypTaI454p/n5EX38xRsA/HSi9qobPZKskM+geysu17Tz1LF9Hh/C8N5hfLMthyIU16Pic4r4W/ZpT6oick7q6a9BzHmeH1r70ivhKyB0qCYRQtpziSpXDSJ44GJXN2IoDt1lIKYX4eDDlmy/tDFVgvrQ7bjxlaU2XiPOdIHpGE/XZ0A63VJzTIyNbFiAcGmC8ij9yy9SGXLJs2OqgJSQndytK5QVAEdKN7ylfxV+/58VEHVg2F/VEH0qbfbjEtRmu5esWXblSt6IgsposKiXYvp1yrEMHEUDv8+uDqyejqd0aQHVKTgsNo36PJlgOah8JQzUmBZe8aS/rpWeZ5wPE0OoWyH45/lbk0ycyZtYQp9niPgnRaO9aGbdLDDTK8MEA6WWXWONALp1dSS+eQJxDzQYrXxY8H2ltPFXFygwX03W6ByQx7R6e/qFRRozgbWV7mlDJ+bvOl3cq749PVUmTvprEoO+hKivTpFniIobaDbggVDhfSnLMblx85HtfIcMRp1Rv8UeinVwRJ/33AK87pGkw8mz/e0g2qMLYFKBkqxTngmKL4w52nWZowOIb/HS3LR8fj8YlqtAWz8K3NsAbrYuoTPBS71CsefL9KlPqEbXuSV9mnOX2hs1MvvB6G/g2jzxruJHt3op8KCpVaYexi EACASbcB uNQ+11xwWD5M11AYAiH08i3MaS+KJwamDwfB34zkPvnFHTbiQPiRuCd9p3BovLzQZVjhUq/hnWbMPZYyUr1N7AOiDoGHCzVpFncMPAxh9zKHY9zV0VS9JrAcwKMX+2K6QUnD5AWYq+60yt3TDAHUiyqWAFA== 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: On Mon, Apr 17, 2023 at 03:56:43PM +0800, Yin Fengwei wrote: > Currently, large folio is not batched added to lru list. Which > cause high lru lock contention after enable large folio for > anonymous mappping. Obviously, I think we should be doing a batched add, but I don't think this is right. > @@ -54,7 +57,12 @@ static inline unsigned pagevec_space(struct pagevec *pvec) > static inline unsigned pagevec_add(struct pagevec *pvec, struct page *page) > { > pvec->pages[pvec->nr++] = page; > - return pagevec_space(pvec); > + pvec->pages_nr += compound_nr(page); > + > + if (pvec->pages_nr > PAGEVEC_SIZE) > + return 0; > + else > + return pagevec_space(pvec); I assume your thinking here is that we should limit the number of pages in the batches, but I think we should allow the number of folios to reach PAGEVEC_SIZE before we drain the batch onto the LRU list. That will reduce the contention on the LRU lock even further.