From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Milian Wolff <milian.wolff@kdab.com>,
linux-perf-users@vger.kernel.org,
Namhyung Kim <namhyung@kernel.org>,
Arnaldo Carvalho de Melo <acme@kenel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: perf 6.9-1 (archlinux) crashes during recording of cycles + raw_syscalls
Date: Tue, 4 Jun 2024 16:02:08 -0300 [thread overview]
Message-ID: <Zl9ksOlHJHnKM70p@x1> (raw)
In-Reply-To: <CAP-5=fVJRr2Qgf88ugEJ2FGerzKNv_dD6XOT_dSuFyYp2ubwSw@mail.gmail.com>
On Tue, Jun 04, 2024 at 11:48:09AM -0700, Ian Rogers wrote:
> On Tue, Jun 4, 2024 at 7:12 AM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Can you please try with the attached and perhaps provide your Tested-by?
> > From ab355e2c6b4cf641a9fff7af38059cf69ac712d5 Mon Sep 17 00:00:00 2001
> > From: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Date: Tue, 4 Jun 2024 11:00:22 -0300
> > Subject: [PATCH 1/1] Revert "perf record: Reduce memory for recording
> > PERF_RECORD_LOST_SAMPLES event"
> > This reverts commit 7d1405c71df21f6c394b8a885aa8a133f749fa22.
> I think we should try to fight back reverts when possible. Reverts are
> removing something somebody poured time and attention into. When a
While in the development phase, yeah, but when we find a regression and
the revert makes it go away, that is the way to go.
The person who poured time on the development gets notified and can
decide if/when to try again.
Millian had to pour time to figure out why something stopped working,
was kind enough to provide the output from multiple tools to help in
fixing the problem and I had to do the bisect to figure out when the
problem happened and to check if reverting it we would have the tool
working again.
If we try to fix this for v6.10 we may end up adding yet another bug, so
the safe thing to do at this point is to do the revert.
We can try improving this once again for v6.11.
> regression has occurred then I think we should add the regression case
> as a test.
Sure, I thought about that as well, will try and have one shell test
with that, referring to this case, for v6.11.
- Arnaldo
next prev parent reply other threads:[~2024-06-04 19:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <23879991.0LEYPuXRzz@milian-workstation>
[not found] ` <Zl8bhWfHSXxs35r2@x1>
2024-06-04 14:12 ` perf 6.9-1 (archlinux) crashes during recording of cycles + raw_syscalls Arnaldo Carvalho de Melo
2024-06-04 18:48 ` Ian Rogers
2024-06-04 19:02 ` Arnaldo Carvalho de Melo [this message]
2024-06-06 22:20 ` Namhyung Kim
2024-06-06 23:17 ` Ian Rogers
2024-06-07 18:26 ` Namhyung Kim
2024-06-04 20:04 ` Milian Wolff
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=Zl9ksOlHJHnKM70p@x1 \
--to=acme@kernel.org \
--cc=acme@kenel.org \
--cc=irogers@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=milian.wolff@kdab.com \
--cc=namhyung@kernel.org \
/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