...
> What I remember is that since perf_sample_data is fairly large,
> unconditionally initializing the whole thing is *slow* (and
> -fauto-var-init=zero will hurt here).
That will hurt everywhere.
I can also imagine it hiding bugs and making people
shrink on-stack arrays to the point where they
* Alexei Starovoitov wrote:
> > This seems to be it... (completely untested)
> >
> > ---
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index 3f7f89ea5e51..918a296d2ca2 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -1032,7
On Fri, Mar 5, 2021 at 7:01 AM Peter Zijlstra wrote:
>
> On Fri, Mar 05, 2021 at 09:36:30AM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 04, 2021 at 07:45:44PM -0800, Linus Torvalds wrote:
> > > That cacheline_aligned goes back many years, this is not new, it
> > > seems to come from back in
On Fri, Mar 05, 2021 at 09:36:30AM +0100, Peter Zijlstra wrote:
> On Thu, Mar 04, 2021 at 07:45:44PM -0800, Linus Torvalds wrote:
> > That cacheline_aligned goes back many years, this is not new, it
> > seems to come from back in 2014: commit 2565711fb7d7 ("perf: Improve
> > the
On Thu, Mar 04, 2021 at 07:45:44PM -0800, Linus Torvalds wrote:
> That cacheline_aligned goes back many years, this is not new, it
> seems to come from back in 2014: commit 2565711fb7d7 ("perf: Improve
> the perf_sample_data struct layout").
long time ago...
> But it really seems entirely
Sp there's a note about new warnings in 5.12-rc1 that I looked at, and
many of the warnings made me go "Whaaa?". They were all of the type
warning: 'perf_event_aux_event' uses dynamic stack allocation
and then when I go look, I see nothing that looks like a dynamic stack
allocation at all.
6 matches
Mail list logo
