[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Ywyp5XmDTJxmmKlN@hirez.programming.kicks-ass.net>
Date: Mon, 29 Aug 2022 13:58:29 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ravi Bangoria <ravi.bangoria@....com>
Cc: acme@...nel.org, alexander.shishkin@...ux.intel.com,
jolsa@...hat.com, namhyung@...nel.org, songliubraving@...com,
eranian@...gle.com, alexey.budankov@...ux.intel.com,
ak@...ux.intel.com, mark.rutland@....com, megha.dey@...el.com,
frederic@...nel.org, maddy@...ux.ibm.com, irogers@...gle.com,
kim.phillips@....com, linux-kernel@...r.kernel.org,
santosh.shukla@....com
Subject: Re: [RFC v2] perf: Rewrite core context handling
On Mon, Aug 29, 2022 at 09:30:50AM +0530, Ravi Bangoria wrote:
> > With this, I can run 'perf test' and perf_event_tests without any error in
> > dmesg. I'll run perf fuzzer over night and see if it reports any issue.
>
> I also ran fuzzer on Intel machine over the weekend. I see only one WARN_ON()
> hit. Otherwise system is running normal. FWIW, I was running fuzzer as normal
> user with perf_event_paranoid=0.
>
> WARNING: CPU: 3 PID: 2840537 at arch/x86/events/core.c:1606 x86_pmu_stop+0xd0/0x100
That's the WARN about PERF_HES_STOPPED already being set.
> Call Trace:
> <TASK>
> x86_pmu_del+0x8e/0x2d0
> ? debug_smp_processor_id+0x17/0x20
> event_sched_out+0x10b/0x2b0
> ? x86_pmu_del+0x5c/0x2d0
> merge_sched_in+0x39f/0x410
And this callchain suggests this is the group_error path.
I can't immediately spot a fail there, but I'll try and stare at it
some.
Powered by blists - more mailing lists