Re: [mm/page_alloc] f26b3fa046: netperf.Throughput_Mbps -18.0% regression

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Waiman Long <longman@redhat.com>
Cc: "ying.huang@intel.com" <ying.huang@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>, Aaron Lu <aaron.lu@intel.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	kernel test robot <oliver.sang@intel.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, kernel test robot <lkp@intel.com>,
	Feng Tang <feng.tang@intel.com>,
	Zhengjun Xing <zhengjun.xing@linux.intel.com>,
	fengwei.yin@intel.com
Subject: Re: [mm/page_alloc] f26b3fa046: netperf.Throughput_Mbps -18.0% regression
Date: Tue, 10 May 2022 12:25:17 -0700	[thread overview]
Message-ID: <CAHk-=wjpkeoyKVf9GVPcddFUDM1+fzFHmoseNZAcqAtjd3D85A@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wiEtdHOeBti66NpSZDQw0KxcU45UNHaO-+Zwbiq3JEu+g@mail.gmail.com>

On Tue, May 10, 2022 at 12:03 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I think the PV case already basically does that - replacing the the
> "store release" with a much more complex sequence. No?

Looking around, the PV case is absolutely horrid, and does a
cmpxchg_release() on the unlock path. Yeah, that would make the unlock
*much* more expensive.

And I guess that's fairly fundamental. Even if you were to avoid an
explicitly atomic access - do the unlock a non-atomic write followed
by a non-atomic "read pending and see if we need to something
expensive", just that check would have to involve at a minimum a
memory barrier, so it ends up being expensive even for the
non-contended case.

              Linus