linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: kernel test robot <yujie.liu@intel.com>,
	 oe-lkp@lists.linux.dev, lkp@intel.com,
	 Andrew Morton <akpm@linux-foundation.org>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	 Hugh Dickins <hughd@google.com>,
	 Nadav Amit <nadav.amit@gmail.com>,
	 Linux Memory Management List <linux-mm@kvack.org>,
	 linux-arch@vger.kernel.org,  feng.tang@intel.com,
	zhengjun.xing@linux.intel.com,  fengwei.yin@intel.com
Subject: Re: [linux-next:master] [mm] 5df397dec7: will-it-scale.per_thread_ops -53.3% regression
Date: Wed, 07 Dec 2022 13:39:48 +0800	[thread overview]
Message-ID: <878rjj22mz.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <CAHk-=whjis-wTZKH20xoBW3=1qyygYoxJORxXx8ZpJbc6KtROw@mail.gmail.com> (Linus Torvalds's message of "Tue, 6 Dec 2022 11:15:09 -0800")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, Dec 6, 2022 at 10:41 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Let me think about this a while, but I think I'll have a patch for you
>> to test once I've dealt with a couple more pull requests.
>
> So here's a trial balloon for you to try if you can see if this mostly
> fixes the regression..
>
> It still limits batching (because unlike the full "gather pages until
> you have to flush", this is all batched under the page table lock. But
> it limits it a bit less, in that it will use a second active batch if
> it only used the initial on-stack one (which is called "local", which
> is not a great name in this context, but whatever).
>
> This _should_ mean that that benchmark will now batch ~512 pages
> instead of just 8.
>
> Which should be pretty much what it effectively used to do before too,
> because the dirty shared page case has always caused that
> "force_flush" thing, so it will have always stopped to flush every
> page directory.
>
> (But we still have that extra rmap flushing limit because there could
> have been _previous_ buffered page pointers that weren't dirty shared
> pages, and we don't want to have to deal with that pain, and might
> have to exit early in order to avoid it)
>
> I can imagine cleaner ways to do this, but they would involve having
> to remember which batch we started having dirty pages in, which is
> more bookkeeping pain than I really think it's worth.
>
> Does this fix the regression?

I have tested the patch, it does fix the regression, the test result is
as follows,

5df397dec7c4c08c 7cc8f9c7146a5c2dad6e71653c4 7763ba2bb16804313aa52bc78ae 
---------------- --------------------------- --------------------------- 
         %stddev     %change         %stddev     %change         %stddev
             \          |                \          |                \  
   2256919 ±  5%    +114.2%    4833919 ±  2%    +116.6%    4889199        will-it-scale.16.threads
      8.17 ±  6%      -8.2        0.00            -8.2        0.00        perf-profile.calltrace.cycles-pp.native_flush_tlb_one_user.flush_tlb_func.__flush_smp_call_function_queue.__sysvec_call_function.sysvec_call_function

Where 5df397dec7c4c08c is first bad commit, 7cc8f9c7146a5c2dad6e71653c4
is its parent commit, and 7763ba2bb16804313aa52bc78ae is the fix
commit.  The benchmark score recovered and CPU cycles for tlb flushing
recovered too.

Best Regards,
Huang, Ying


  parent reply	other threads:[~2022-12-07  5:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05  8:59 kernel test robot
2022-12-05 20:43 ` Linus Torvalds
2022-12-06  2:02   ` Huang, Ying
2022-12-06 18:41     ` Linus Torvalds
     [not found]       ` <CAHk-=whjis-wTZKH20xoBW3=1qyygYoxJORxXx8ZpJbc6KtROw@mail.gmail.com>
2022-12-07  5:39         ` Huang, Ying [this message]
2022-12-07  5:54           ` Hugh Dickins
2022-12-07 20:17           ` Linus Torvalds
2022-12-07 22:20             ` Andrew Morton
2022-12-07  2:12   ` Yujie Liu

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=878rjj22mz.fsf@yhuang6-desk2.ccr.corp.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=feng.tang@intel.com \
    --cc=fengwei.yin@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=nadav.amit@gmail.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=torvalds@linux-foundation.org \
    --cc=yujie.liu@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