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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76A54C433EF for ; Thu, 7 Oct 2021 23:35:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F352061076 for ; Thu, 7 Oct 2021 23:35:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F352061076 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 907F2900002; Thu, 7 Oct 2021 19:35:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B7E16B0071; Thu, 7 Oct 2021 19:35:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7808F900002; Thu, 7 Oct 2021 19:35:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0025.hostedemail.com [216.40.44.25]) by kanga.kvack.org (Postfix) with ESMTP id 67DD36B006C for ; Thu, 7 Oct 2021 19:35:56 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1F9132DEA9 for ; Thu, 7 Oct 2021 23:35:56 +0000 (UTC) X-FDA: 78671251512.17.DB8FBAC Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf19.hostedemail.com (Postfix) with ESMTP id A5B70B0010A0 for ; Thu, 7 Oct 2021 23:35:55 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id A45D661381; Thu, 7 Oct 2021 23:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1633649754; bh=bVw76LSm8d1+ywKjsFtNWQZs2s9sQ+LZlQ9anViHYT8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=B+8G1WgXzgfwoaESBkKS7k7JTnDSuSB1JkYMfxlUS5hgfItE/d564svZFEhVaMTTI yxRtiINNQVv63wYsdYsQ4v6TFnOOC9pI4beAIr1AjqTUslg2Q4Ri4kBwogiVIRi6SO uQA3+uuW1nd7wIfgK1TuSfK/QCEvk4DfjHjdes20= Date: Thu, 7 Oct 2021 16:35:54 -0700 From: Andrew Morton To: Matthew Wilcox Cc: Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: Optimise put_pages_list() Message-Id: <20211007163554.d9088a65f0e293e2bd906a56@linux-foundation.org> In-Reply-To: References: <20211007192138.561673-1-willy@infradead.org> <20211007123109.6a49c7c625e414acf7546c89@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A5B70B0010A0 X-Stat-Signature: r7md9xugpa8jgmosf6ibpjkw5947rax4 Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=B+8G1WgX; spf=pass (imf19.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam06 X-HE-Tag: 1633649755-788020 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 Thu, 7 Oct 2021 21:55:21 +0100 Matthew Wilcox wrote: > On Thu, Oct 07, 2021 at 12:31:09PM -0700, Andrew Morton wrote: > > On Thu, 7 Oct 2021 20:21:37 +0100 "Matthew Wilcox (Oracle)" wrote: > > > > > Instead of calling put_page() one page at a time, pop pages off > > > the list if their refcount was too high and pass the remainder to > > > put_unref_page_list(). This should be a speed improvement, but I have > > > no measurements to support that. Current callers do not care about > > > performance, but I hope to add some which do. > > > > Don't you think it would actually be slower to take an additional pass > > across the list? If the list is long enough to cause cache thrashing. > > Maybe it's faster for small lists. > > My first response is an appeal to authority -- release_pages() does > this same thing. Only it takes an array, constructs a list and passes > that to put_unref_page_list(). So if that's slower (and lists _are_ > slower than arrays), we should have a put_unref_page_array(). And put_unref_page_list() does two passes across the list! Here is my beautiful release_pages(), as disrtibuted in linux-2.5.33: void release_pages(struct page **pages, int nr) { int i; struct pagevec pages_to_free; struct zone *zone = NULL; pagevec_init(&pages_to_free); for (i = 0; i < nr; i++) { struct page *page = pages[i]; struct zone *pagezone; if (PageReserved(page) || !put_page_testzero(page)) continue; pagezone = page_zone(page); if (pagezone != zone) { if (zone) spin_unlock_irq(&zone->lru_lock); zone = pagezone; spin_lock_irq(&zone->lru_lock); } if (TestClearPageLRU(page)) del_page_from_lru(zone, page); if (page_count(page) == 0) { if (!pagevec_add(&pages_to_free, page)) { spin_unlock_irq(&zone->lru_lock); pagevec_free(&pages_to_free); pagevec_init(&pages_to_free); spin_lock_irq(&zone->lru_lock); } } } if (zone) spin_unlock_irq(&zone->lru_lock); pagevec_free(&pages_to_free); } I guess the current version is some commentary on the aging process? > Second, we can follow through the code paths and reason about it. > > Before: > > while (!list_empty(pages)) { > put_page(victim); > page = compound_head(page); > if (put_page_testzero(page)) > __put_page(page); > __put_single_page(page) > __page_cache_release(page); > mem_cgroup_uncharge(page); > <--- > free_unref_page(page, 0); > free_unref_page_prepare() > local_lock_irqsave(&pagesets.lock, flags); > free_unref_page_commit(page, pfn, migratetype, order); > local_unlock_irqrestore(&pagesets.lock, flags); > > After: > > free_unref_page_list(pages); > list_for_each_entry_safe(page, next, list, lru) { > if (!free_unref_page_prepare(page, pfn, 0)) { > } > > local_lock_irqsave(&pagesets.lock, flags); > list_for_each_entry_safe(page, next, list, lru) { > free_unref_page_commit() > } > local_unlock_irqrestore(&pagesets.lock, flags); > > So the major win here is that we disable/enable interrupts once per > batch rather than once per page. Perhaps that's faster if the list is fully cached. Any feelings for how often release_pages() will be passed a huge enough list for this to occur?