linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: kernel test robot <oliver.sang@intel.com>
Cc: Sandeep Patil <sspatil@android.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, kernel test robot <lkp@intel.com>,
	"Huang, Ying" <ying.huang@intel.com>,
	Feng Tang <feng.tang@intel.com>,
	Zhengjun Xing <zhengjun.xing@linux.intel.com>
Subject: Re: [pipe] 3a34b13a88: hackbench.throughput -12.6% regression
Date: Mon, 2 Aug 2021 10:06:59 -0700	[thread overview]
Message-ID: <CAHk-=whr-zgf41B0BPsWnL-WWqhdk71rKffhV0fzdCuem3=SCQ@mail.gmail.com> (raw)
In-Reply-To: <20210802024945.GA8372@xsang-OptiPlex-9020>

On Sun, Aug 1, 2021 at 7:31 PM kernel test robot <oliver.sang@intel.com> wrote:
>
> FYI, we noticed a -12.6% regression of hackbench.throughput due to commit:

I had already forgotten how sensitive hackbench is to pipe wakeups.

I think it's all good for stable, and we can live with this -
particularly since I'm not sure how much hackbench really matters.

But it might be one of those things where it is a good idea to make
the crazy epoll case explicitly special.

Sandeep, does something like the attached patch (written to be on top
of the existing one) work for you?

It's not a great patch - I'd like to catch _just_ the broken EPOLLET
case, but this patch triggers on any select/poll usage - but it might
be a good idea to do it this way simply because it now separates out
the "ok, now we need to do stupid things" logic, so that we *could*
make that "stupid things" test tighter some day.

And I think it's actually better to make sure that the unnecessary
extra wakeup be the _last_ one a write() system call does, not the
first one. So this may be the way to go for that reason too.

This all probably doesn't matter one whit, but hey, I love how the
kernel test robot gives us heads-up about performance anomalies, so I
try to take them seriously when they aren't totally strange (which
happens sometimes: some of the benchmarks end up having subtle cache
placement effects)

                 Linus

  reply	other threads:[~2021-08-02 17:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02  2:49 [pipe] 3a34b13a88: hackbench.throughput -12.6% regression kernel test robot
2021-08-02 17:06 ` Linus Torvalds [this message]
2021-08-02 17:14   ` Linus Torvalds
2021-08-10 18:24     ` Sandeep Patil
2021-08-18 15:31     ` Mel Gorman
2021-08-18 18:17       ` Linus Torvalds
2021-08-11 15:46   ` Sandeep Patil

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='CAHk-=whr-zgf41B0BPsWnL-WWqhdk71rKffhV0fzdCuem3=SCQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=feng.tang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=mtk.manpages@gmail.com \
    --cc=oliver.sang@intel.com \
    --cc=sspatil@android.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).