From: Ingo Molnar <mingo@elte.hu>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>,
Corey Ashford <cjashfor@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] perf_counter: add more context information
Date: Thu, 2 Apr 2009 20:34:17 +0200 [thread overview]
Message-ID: <20090402183417.GA843@elte.hu> (raw)
In-Reply-To: <1238696998.5133.44.camel@laptop>
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Thu, 2009-04-02 at 20:18 +0200, Ingo Molnar wrote:
> > * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > > On Thu, 2009-04-02 at 13:36 +0200, Ingo Molnar wrote:
> > >
> > > > > -#define MAX_STACK_DEPTH 255
> > > > > +#define MAX_STACK_DEPTH 254
> > > > >
> > > > > struct perf_callchain_entry {
> > > > > - u64 nr;
> > > > > + u32 nr, hv, kernel, user;
> > > > > u64 ip[MAX_STACK_DEPTH];
> > > > > };
> > >
> > > Oh, and Paul suggested using u16s right after I send it out. So
> > > I'll either send an update or send a incremental in case you
> > > already applied it.
> >
> > yes, that's probably a good idea. Although u8 might be even better -
> > do we ever want to do more than 256 deep stack vectors? Even those
> > would take quite some time to construct and pass down.
>
> We'd have to pad it with 4 more bytes to remain u64 aligned,
ok, indeed.
> [...] also, why restrict ourselves. That MAX_STACK_DEPTH limit is
> trivially fixable if indeed someone finds its insufficient.
well .. think about it: walking more than 256 stack frames for every
IRQ event? Getting backtraces like:
<func_0+0x123>
<func_1+0x123>
<func_2+0x123>
<func_3+0x123>
<func_4+0x123>
<func_5+0x123>
<func_6+0x123>
<func_7+0x123>
<func_8+0x123>
<func_9+0x123>
<func_10+0x123>
<func_11+0x123>
<func_12+0x123>
<func_13+0x123>
<func_14+0x123>
<func_15+0x123>
<func_16+0x123>
<func_17+0x123>
<func_18+0x123>
<func_19+0x123>
<func_20+0x123>
<func_21+0x123>
<func_22+0x123>
<func_23+0x123>
<func_24+0x123>
<func_25+0x123>
<func_26+0x123>
<func_27+0x123>
<func_28+0x123>
<func_29+0x123>
<func_30+0x123>
<func_31+0x123>
<func_32+0x123>
<func_33+0x123>
<func_34+0x123>
<func_35+0x123>
<func_36+0x123>
<func_37+0x123>
<func_38+0x123>
<func_39+0x123>
<func_40+0x123>
<func_41+0x123>
<func_42+0x123>
<func_43+0x123>
<func_44+0x123>
<func_45+0x123>
<func_46+0x123>
<func_47+0x123>
<func_48+0x123>
<func_49+0x123>
<func_50+0x123>
<func_51+0x123>
<func_52+0x123>
<func_53+0x123>
<func_54+0x123>
<func_55+0x123>
<func_56+0x123>
<func_57+0x123>
<func_58+0x123>
<func_59+0x123>
<func_60+0x123>
<func_61+0x123>
<func_62+0x123>
<func_63+0x123>
<func_64+0x123>
<func_65+0x123>
<func_66+0x123>
<func_67+0x123>
<func_68+0x123>
<func_69+0x123>
<func_70+0x123>
<func_71+0x123>
<func_72+0x123>
<func_73+0x123>
<func_74+0x123>
<func_75+0x123>
<func_76+0x123>
<func_77+0x123>
<func_78+0x123>
<func_79+0x123>
<func_80+0x123>
<func_81+0x123>
<func_82+0x123>
<func_83+0x123>
<func_84+0x123>
<func_85+0x123>
<func_86+0x123>
<func_87+0x123>
<func_88+0x123>
<func_89+0x123>
<func_90+0x123>
<func_91+0x123>
<func_92+0x123>
<func_93+0x123>
<func_94+0x123>
<func_95+0x123>
<func_96+0x123>
<func_97+0x123>
<func_98+0x123>
<func_99+0x123>
<func_100+0x123>
<func_101+0x123>
<func_102+0x123>
<func_103+0x123>
<func_104+0x123>
<func_105+0x123>
<func_106+0x123>
<func_107+0x123>
<func_108+0x123>
<func_109+0x123>
<func_110+0x123>
<func_111+0x123>
<func_112+0x123>
<func_113+0x123>
<func_114+0x123>
<func_115+0x123>
<func_116+0x123>
<func_117+0x123>
<func_118+0x123>
<func_119+0x123>
<func_120+0x123>
<func_121+0x123>
<func_122+0x123>
<func_123+0x123>
<func_124+0x123>
<func_125+0x123>
<func_126+0x123>
<func_127+0x123>
<func_128+0x123>
<func_129+0x123>
<func_130+0x123>
<func_131+0x123>
<func_132+0x123>
<func_133+0x123>
<func_134+0x123>
<func_135+0x123>
<func_136+0x123>
<func_137+0x123>
<func_138+0x123>
<func_139+0x123>
<func_140+0x123>
<func_141+0x123>
<func_142+0x123>
<func_143+0x123>
<func_144+0x123>
<func_145+0x123>
<func_146+0x123>
<func_147+0x123>
<func_148+0x123>
<func_149+0x123>
<func_150+0x123>
<func_151+0x123>
<func_152+0x123>
<func_153+0x123>
<func_154+0x123>
<func_155+0x123>
<func_156+0x123>
<func_157+0x123>
<func_158+0x123>
<func_159+0x123>
<func_160+0x123>
<func_161+0x123>
<func_162+0x123>
<func_163+0x123>
<func_164+0x123>
<func_165+0x123>
<func_166+0x123>
<func_167+0x123>
<func_168+0x123>
<func_169+0x123>
<func_170+0x123>
<func_171+0x123>
<func_172+0x123>
<func_173+0x123>
<func_174+0x123>
<func_175+0x123>
<func_176+0x123>
<func_177+0x123>
<func_178+0x123>
<func_179+0x123>
<func_180+0x123>
<func_181+0x123>
<func_182+0x123>
<func_183+0x123>
<func_184+0x123>
<func_185+0x123>
<func_186+0x123>
<func_187+0x123>
<func_188+0x123>
<func_189+0x123>
<func_190+0x123>
<func_191+0x123>
<func_192+0x123>
<func_193+0x123>
<func_194+0x123>
<func_195+0x123>
<func_196+0x123>
<func_197+0x123>
<func_198+0x123>
<func_199+0x123>
<func_200+0x123>
<func_201+0x123>
<func_202+0x123>
<func_203+0x123>
<func_204+0x123>
<func_205+0x123>
<func_206+0x123>
<func_207+0x123>
<func_208+0x123>
<func_209+0x123>
<func_210+0x123>
<func_211+0x123>
<func_212+0x123>
<func_213+0x123>
<func_214+0x123>
<func_215+0x123>
<func_216+0x123>
<func_217+0x123>
<func_218+0x123>
<func_219+0x123>
<func_220+0x123>
<func_221+0x123>
<func_222+0x123>
<func_223+0x123>
<func_224+0x123>
<func_225+0x123>
<func_226+0x123>
<func_227+0x123>
<func_228+0x123>
<func_229+0x123>
<func_230+0x123>
<func_231+0x123>
<func_232+0x123>
<func_233+0x123>
<func_234+0x123>
<func_235+0x123>
<func_236+0x123>
<func_237+0x123>
<func_238+0x123>
<func_239+0x123>
<func_240+0x123>
<func_241+0x123>
<func_242+0x123>
<func_243+0x123>
<func_244+0x123>
<func_245+0x123>
<func_246+0x123>
<func_247+0x123>
<func_248+0x123>
<func_249+0x123>
<func_250+0x123>
<func_251+0x123>
<func_252+0x123>
<func_253+0x123>
<func_254+0x123>
<func_255+0x123>
<func_256+0x123>
<func_257+0x123>
<func_258+0x123>
<func_259+0x123>
<func_260+0x123>
<func_261+0x123>
<func_262+0x123>
<func_263+0x123>
<func_264+0x123>
<func_265+0x123>
<func_266+0x123>
<func_267+0x123>
<func_268+0x123>
<func_269+0x123>
does that make much sense _per event_? How do you visualize it?
But yeah ... i could imagine some user-space craziness and since we
want to align to u64 i guess that pretty much settles it to u16.
Ingo
next prev parent reply other threads:[~2009-04-02 18:34 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-02 9:11 [PATCH 0/6] more perf_counter stuff Peter Zijlstra
2009-04-02 9:11 ` [PATCH 1/6] perf_counter: move the event overflow output bits to record_type Peter Zijlstra
2009-04-02 11:28 ` Ingo Molnar
2009-04-02 11:43 ` Ingo Molnar
2009-04-02 11:47 ` Peter Zijlstra
2009-04-02 12:03 ` [tip:perfcounters/core] " Peter Zijlstra
2009-04-02 22:33 ` [PATCH 1/6] " Corey Ashford
2009-04-02 23:27 ` Corey Ashford
2009-04-03 6:50 ` Peter Zijlstra
2009-04-03 7:30 ` Corey Ashford
2009-04-02 9:12 ` [PATCH 2/6] RFC perf_counter: singleshot support Peter Zijlstra
2009-04-02 10:51 ` Ingo Molnar
2009-04-02 11:48 ` Peter Zijlstra
2009-04-02 12:26 ` Ingo Molnar
2009-04-02 21:23 ` Paul Mackerras
2009-04-02 12:18 ` Peter Zijlstra
2009-04-02 18:10 ` Ingo Molnar
2009-04-02 18:33 ` Peter Zijlstra
2009-04-02 9:12 ` [PATCH 3/6] perf_counter: per event wakeups Peter Zijlstra
2009-04-02 11:32 ` Ingo Molnar
2009-04-02 12:03 ` [tip:perfcounters/core] " Peter Zijlstra
2009-04-02 9:12 ` [PATCH 4/6] perf_counter: kerneltop: update to new ABI Peter Zijlstra
2009-04-02 12:03 ` [tip:perfcounters/core] " Peter Zijlstra
2009-04-02 13:35 ` Jaswinder Singh Rajput
2009-04-02 13:59 ` Jaswinder Singh Rajput
2009-04-02 18:11 ` Ingo Molnar
2009-04-02 18:22 ` Jaswinder Singh Rajput
2009-04-02 18:28 ` Ingo Molnar
2009-04-02 18:38 ` Jaswinder Singh Rajput
2009-04-02 19:20 ` Ingo Molnar
2009-04-02 18:51 ` Jaswinder Singh Rajput
2009-04-02 18:32 ` Jaswinder Singh Rajput
2009-04-02 9:12 ` [PATCH 5/6] perf_counter: add more context information Peter Zijlstra
2009-04-02 11:36 ` Ingo Molnar
2009-04-02 11:46 ` Peter Zijlstra
2009-04-02 18:16 ` Ingo Molnar
2009-04-02 11:48 ` Peter Zijlstra
2009-04-02 18:18 ` Ingo Molnar
2009-04-02 18:29 ` Peter Zijlstra
2009-04-02 18:34 ` Ingo Molnar [this message]
2009-04-02 18:42 ` Peter Zijlstra
2009-04-02 19:19 ` Ingo Molnar
2009-04-02 12:04 ` [tip:perfcounters/core] " Peter Zijlstra
2009-04-03 12:50 ` [PATCH 5/6] " Peter Zijlstra
2009-04-03 18:25 ` Corey Ashford
2009-04-06 11:01 ` Peter Zijlstra
2009-04-06 11:07 ` Peter Zijlstra
2009-04-06 18:53 ` Corey Ashford
2009-04-06 19:06 ` Peter Zijlstra
2009-04-06 20:16 ` Corey Ashford
2009-04-06 20:46 ` Peter Zijlstra
2009-04-06 21:15 ` Corey Ashford
2009-04-06 21:21 ` Peter Zijlstra
2009-04-06 21:33 ` Corey Ashford
2009-04-07 7:11 ` Peter Zijlstra
2009-04-07 16:27 ` Corey Ashford
2009-04-02 9:12 ` [PATCH 6/6] perf_counter: update mmap() counter read Peter Zijlstra
2009-04-02 12:04 ` [tip:perfcounters/core] " Peter Zijlstra
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=20090402183417.GA843@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.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