From: Frederic Weisbecker <frederic@kernel.org>
To: Oliver Sang <oliver.sang@intel.com>
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com
Subject: Re: [linus:master] [timers] 7ee9887703: stress-ng.uprobe.ops_per_sec -17.1% regression
Date: Thu, 4 Apr 2024 16:05:37 +0200 [thread overview]
Message-ID: <Zg6zscsaZ0OA14yn@localhost.localdomain> (raw)
In-Reply-To: <Zgtjdd0C2FzYVBto@xsang-OptiPlex-9020>
Le Tue, Apr 02, 2024 at 09:46:29AM +0800, Oliver Sang a écrit :
> hi, Frederic Weisbecker,
>
> On Tue, Apr 02, 2024 at 12:46:15AM +0200, Frederic Weisbecker wrote:
> > Le Wed, Mar 27, 2024 at 04:39:17PM +0800, kernel test robot a écrit :
> > >
> > >
> > > Hello,
> > >
> > >
> > > we reported
> > > "[tip:timers/core] [timers] 7ee9887703: netperf.Throughput_Mbps -1.2% regression"
> > > in
> > > https://lore.kernel.org/all/202403011511.24defbbd-oliver.sang@intel.com/
> > >
> > > now we noticed this commit is in mainline and we captured further results.
> > >
> > > still include netperf results for complete. below details FYI.
> > >
> > >
> > > kernel test robot noticed a -17.1% regression of stress-ng.uprobe.ops_per_sec
> > > on:
> >
> > The good news is that I can reproduce.
> > It has made me spot something already:
> >
> > https://lore.kernel.org/lkml/ZgsynV536q1L17IS@pavilion.home/T/#m28c37a943fdbcbadf0332cf9c32c350c74c403b0
> >
> > But that's not enough to fix the regression. Investigation continues...
>
> Thanks a lot for information! if you want us test any patch, please let us know.
The good news is that I can reproduce on two CPUs with just this:
./tmp-pkg/stress-ng/src/stress-ng/stress-ng --uprobe-ops 1 --uprobe 2 --timeout 5 --metrics-brief
This reminds me I should try on a single CPU.
Anyway but the big problem with stress-ng.uprobe is that it consists in
triggering uprobes events and consuming /sys/kernel/tracing/trace_pipe
This makes this testcase nearly impossible to analyse because I can't use any
tracing: the traces are consumed by the testcase. That alone took me quite
some time to figure out.
Then I tried using perf event to do the tracing, as it relies on a different
ring buffer. It works but traces generate ring buffer consumer wake up, which
doesn't work as we are analysing code that depends on idle behaviour.
Then I tried hacking stress-uprobe.c so that the consumed traces are recorded
in a buffer that I writeback in the end. So I can add my own tracepoints in
the flow. And it works but that again doesn't mix up well with tracing idle
behaviour, similar to perf event: the fact that the testcase waits on
/sys/kernel/tracing/trace_pipe produce wake ups from idle while a trace happen
on idle. And that noise ruins the tracing.
So I'm kind of running out of options for now :-/
next prev parent reply other threads:[~2024-04-04 14:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 8:39 [linus:master] [timers] 7ee9887703: stress-ng.uprobe.ops_per_sec -17.1% regression kernel test robot
2024-04-01 22:46 ` Frederic Weisbecker
2024-04-02 1:46 ` Oliver Sang
2024-04-04 14:05 ` Frederic Weisbecker [this message]
2024-04-25 8:23 ` Anna-Maria Behnsen
2024-04-25 10:15 ` Christian Loehle
2024-04-26 10:15 ` Anna-Maria Behnsen
2024-04-26 11:35 ` Frederic Weisbecker
2024-04-26 15:39 ` Christian Loehle
2024-04-26 6:53 ` Oliver Sang
2024-04-26 16:03 ` Rafael J. Wysocki
2024-04-29 7:53 ` Lukasz Luba
2024-04-29 9:26 ` Anna-Maria Behnsen
2024-04-29 10:40 ` Anna-Maria Behnsen
2024-04-29 17:02 ` Rafael J. Wysocki
2024-05-02 12:56 ` Anna-Maria Behnsen
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=Zg6zscsaZ0OA14yn@localhost.localdomain \
--to=frederic@kernel.org \
--cc=anna-maria@linutronix.de \
--cc=feng.tang@intel.com \
--cc=fengwei.yin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=tglx@linutronix.de \
--cc=ying.huang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.