linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Clark <james.clark@arm.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: linux-perf-users <linux-perf-users@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>
Subject: Re: [PATCH] perf: Fix "Track with sched_switch" test by not printing warnings in quiet mode
Date: Wed, 12 Oct 2022 18:12:37 +0100	[thread overview]
Message-ID: <e0b47b51-87f0-42db-4a76-b240bf07cd41@arm.com> (raw)
In-Reply-To: <CAM9d7cgNrZ6iwRQsGHWGLWCd7cJm+L6UOU9BiGGgTVPdJ0_GJQ@mail.gmail.com>



On 12/10/2022 17:50, Namhyung Kim wrote:
> On Wed, Oct 12, 2022 at 4:13 AM James Clark <james.clark@arm.com> wrote:
>>
>>
>>
>> On 12/10/2022 12:10, James Clark wrote:
>>> Especially when CONFIG_LOCKDEP and other debug configs are enabled,
>>> Perf can print the following warning when running the "Track with
>>> sched_switch" test:
>>
>> Oops got the wrong test name here and in the title. Should be "kernel
>> lock contention analysis test"
> 
> Could you please resend?
> 
>>
>>>
>>>   Warning:
>>>   Processed 1378918 events and lost 4 chunks!
>>>
>>>   Check IO/CPU overload!
>>>
>>>   Warning:
>>>   Processed 4593325 samples and lost 70.00%!
>>>
>>> The test already supplies -q to run in quiet mode, so extend quiet mode
>>> to perf_stdio__warning() and also ui__warning() for consistency.
> 
> I'm not sure if suppressing the warnings with -q is a good thing.
> Maybe we need to separate warning/debug messages from the output.

I don't see the issue with warnings being suppressed in quiet mode as
long as errors are still printed. In other cases warnings have already
been suppressed by quiet mode and this site is the odd one out.

What use case are you thinking of where someone explicitly adds -q but
wants to see non fatal warnings?

Thanks
James

> 
> Thanks,
> Namhyung
> 
> 
>>>
>>> This fixes the following failure due to the extra lines counted:
>>>
>>>   perf test "lock cont" -vvv
>>>
>>>   82: kernel lock contention analysis test                            :
>>>   --- start ---
>>>   test child forked, pid 3125
>>>   Testing perf lock record and perf lock contention
>>>   [Fail] Recorded result count is not 1: 9
>>>   test child finished with -1
>>>   ---- end ----
>>>   kernel lock contention analysis test: FAILED!
>>>
>>> Fixes: ec685de25b67 ("perf test: Add kernel lock contention test")
>>> Cc: Namhyung Kim <namhyung@kernel.org>
>>> Signed-off-by: James Clark <james.clark@arm.com>
>>> ---
>>>  tools/perf/ui/util.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/tools/perf/ui/util.c b/tools/perf/ui/util.c
>>> index 689b27c34246..1d38ddf01b60 100644
>>> --- a/tools/perf/ui/util.c
>>> +++ b/tools/perf/ui/util.c
>>> @@ -15,6 +15,9 @@ static int perf_stdio__error(const char *format, va_list args)
>>>
>>>  static int perf_stdio__warning(const char *format, va_list args)
>>>  {
>>> +     if (quiet)
>>> +             return 0;
>>> +
>>>       fprintf(stderr, "Warning:\n");
>>>       vfprintf(stderr, format, args);
>>>       return 0;
>>> @@ -45,6 +48,8 @@ int ui__warning(const char *format, ...)
>>>  {
>>>       int ret;
>>>       va_list args;
>>> +     if (quiet)
>>> +             return 0;
>>>
>>>       va_start(args, format);
>>>       ret = perf_eops->warning(format, args);

  reply	other threads:[~2022-10-12 17:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 11:10 [PATCH] perf: Fix "Track with sched_switch" test by not printing warnings in quiet mode James Clark
2022-10-12 11:13 ` James Clark
2022-10-12 16:50   ` Namhyung Kim
2022-10-12 17:12     ` James Clark [this message]
2022-10-13 16:57       ` Namhyung Kim
2022-10-14  9:47         ` James Clark
2022-10-17 12:33           ` Arnaldo Carvalho de Melo
2022-10-17 23:47             ` Namhyung Kim

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=e0b47b51-87f0-42db-4a76-b240bf07cd41@arm.com \
    --to=james.clark@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).