[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZfPBOyONqBnhUa3R@casper.infradead.org>
Date: Fri, 15 Mar 2024 03:32:11 +0000
From: Matthew Wilcox <willy@...radead.org>
To: kernel test robot <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>, Mel Gorman <mgorman@...e.de>,
Ryan Roberts <ryan.roberts@....com>, linux-mm@...ck.org,
ying.huang@...el.com, feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linus:master] [mm] 99fbb6bfc1: will-it-scale.per_process_ops
-4.7% regression
On Fri, Mar 15, 2024 at 11:07:58AM +0800, kernel test robot wrote:
> kernel test robot noticed a -4.7% regression of will-it-scale.per_process_ops on:
>
> commit: 99fbb6bfc16f202adc411ad5d353db214750d121 ("mm: make folios_put() the basis of release_pages()")
I was kind of hoping you'd report this before it hit Linus' tree ...
I did post it last August without any response from the bot, and it's
been in Andrew's tree for a couple of weeks. Is there a better way
to draw the attention of the performance bots?
> testcase: will-it-scale
> test machine: 104 threads 2 sockets (Skylake) with 192G memory
> parameters:
>
> nr_task: 100%
> mode: process
> test: page_fault2
OK, this makes sense. mmap(128MB, MAP_PRIVATE), write to all the pages,
then unmap them. That's going to throw 32k pages at the page freeing
path.
Can you add this patch and rerun the test?
diff --git a/include/linux/pagevec.h b/include/linux/pagevec.h
index 87cc678adc85..67f10b8810a8 100644
--- a/include/linux/pagevec.h
+++ b/include/linux/pagevec.h
@@ -11,8 +11,8 @@
#include <linux/types.h>
-/* 15 pointers + header align the folio_batch structure to a power of two */
-#define PAGEVEC_SIZE 15
+/* 31 pointers + header align the folio_batch structure to a power of two */
+#define PAGEVEC_SIZE 31
struct folio;
Powered by blists - more mailing lists