linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <edumazet@google.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: kernel test robot <oliver.sang@intel.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	0day robot <lkp@intel.com>, Michal Hocko <mhocko@kernel.org>,
	Shakeel Butt <shakeelb@google.com>, Wei Xu <weixugc@google.com>,
	Greg Thelen <gthelen@google.com>, Hugh Dickins <hughd@google.com>,
	David Rientjes <rientjes@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, "Huang, Ying" <ying.huang@intel.com>,
	"Tang, Feng" <feng.tang@intel.com>,
	zhengjun.xing@linux.intel.com, fengwei.yin@intel.com,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [mm/page_alloc] 8212a964ee: vm-scalability.throughput 30.5% improvement
Date: Sat, 12 Mar 2022 15:26:12 -0800	[thread overview]
Message-ID: <CANn89i+fM0k+=Qw0M0fso1f-Ya8--5+==gtcWqCpo=Gu-ca1Ow@mail.gmail.com> (raw)
In-Reply-To: <15307f8a-c202-75d8-1361-dae0146df734@suse.cz>

On Sat, Mar 12, 2022 at 10:59 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 3/12/22 16:43, kernel test robot wrote:
> >
> >
> > Greeting,
> >
> > FYI, we noticed a 30.5% improvement of vm-scalability.throughput due to commit:
> >
> >
> > commit: 8212a964ee020471104e34dce7029dec33c218a9 ("Re: [PATCH v2] mm/page_alloc: call check_new_pages() while zone spinlock is not held")
> > url: https://github.com/0day-ci/linux/commits/Mel-Gorman/Re-PATCH-v2-mm-page_alloc-call-check_new_pages-while-zone-spinlock-is-not-held/20220309-203504
> > patch link: https://lore.kernel.org/lkml/20220309123245.GI15701@techsingularity.net
>
> Heh, that's weird. I would expect some improvement from Eric's patch,
> but this seems to be actually about Mel's "mm/page_alloc: check
> high-order pages for corruption during PCP operations" applied directly
> on 5.17-rc7 per the github url above. This was rather expected to make
> performance worse if anything, so maybe the improvement is due to some
> unexpected side-effect of different inlining decisions or cache alignment...
>

I doubt this has anything to do with inlining or cache alignment.

I am not familiar with the benchmark, but its name
(anon-w-rand-hugetlb) hints at hugetlb ?

After Mel fix, we go over 512 'struct page' to perform sanity checks,
thus loading into cpu caches the 512 cache lines.

This caching is done while no lock is held.

If after this huge page allocation some mm operation needs to access
these 512 struct pages,
while holding a lock, then sure, there is a huge gain.

  reply	other threads:[~2022-03-12 23:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 17:02 [PATCH v2] mm/page_alloc: call check_new_pages() while zone spinlock is not held Eric Dumazet
2022-03-04 19:19 ` Shakeel Butt
2022-03-06 22:15 ` David Rientjes
2022-03-07  9:15 ` Mel Gorman
2022-03-08 23:49   ` Eric Dumazet
2022-03-09 12:32     ` Mel Gorman
2022-03-09 17:32       ` Eric Dumazet
2022-03-12 15:43       ` [mm/page_alloc] 8212a964ee: vm-scalability.throughput 30.5% improvement kernel test robot
2022-03-12 18:58         ` Vlastimil Babka
2022-03-12 23:26           ` Eric Dumazet [this message]
2022-03-13  9:28             ` Vlastimil Babka
2022-03-13 21:10               ` Eric Dumazet
2022-03-13 21:18                 ` Matthew Wilcox
2022-03-13 21:27                   ` Eric Dumazet
2022-03-13 21:36                     ` Eric Dumazet
2022-03-14  9:09                 ` Vlastimil Babka
2022-03-07  9:24 ` [PATCH v2] mm/page_alloc: call check_new_pages() while zone spinlock is not held Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANn89i+fM0k+=Qw0M0fso1f-Ya8--5+==gtcWqCpo=Gu-ca1Ow@mail.gmail.com' \
    --to=edumazet@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=eric.dumazet@gmail.com \
    --cc=feng.tang@intel.com \
    --cc=fengwei.yin@intel.com \
    --cc=gthelen@google.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=oliver.sang@intel.com \
    --cc=rientjes@google.com \
    --cc=shakeelb@google.com \
    --cc=vbabka@suse.cz \
    --cc=weixugc@google.com \
    --cc=ying.huang@intel.com \
    --cc=zhengjun.xing@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).