On Wed, Jun 6, 2012 at 2:21 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> I have an incomplete patch to fix bug 1961 (CPU profiler crashing squid
> whenever AIO or other threads are used).
>
> So far I have a timer class whose constructor/destructor perform the timer
> setup and stats recording. That is attached.
>
> The old profiler was done in a way which allowed live run-time snapshot
> cachemgr report to be taken without stopping any timers. I've hooked these
> classes into that reporting structure, but at present they will result in
> the snapshots only recording *finished* timers, not the currently active
> incomplete ones.
>
> I'm thinking keeping the stack/list of timers from the old design but only
> using it to dump a list of "currently incomplete" function calls instead of
> using it to add incremental bits of timers to the report.
>
> Does anyone have any other inspirational thoughts about how to keep that
> kind of detail peeking using these classes in a multi-threaded soup of code?
I like the idea,
I'm a bit worried about xprof_initlib at each timer stop; maybe we
could be lighter-weight when collecting stats? E.g. keep the stats
local to the profiler, and register each profiler with cachemgr
instead? This would lower overhead, increase data locality and possbly
performance.
But this is implementation nitpicking :)
Regarding the fact that the profiler can't record current calls, I
think it's minor and can be skipped.
-- /kinkieReceived on Wed Jun 06 2012 - 08:35:01 MDT
This archive was generated by hypermail 2.2.0 : Thu Jun 07 2012 - 12:00:04 MDT