Re: profiling aufs

On 6 Oct 2002, at 16:21, Robert Collins <robertc@squid-cache.org> wrote:

> Here are my thoughts on the changes needed to use the hires
> profiling on aufs:
>
> 1) during thread creation, or at the first prof_start in a new thread,
> create a new profiling data block, and save the pointer in a) a global
> list of profiling data blocks, and b) a pre-reserved pthread_key.
> 2) prof_start and prof_end use pthread_getspecific() to access the
> thread specific data block.
> 3) prof_event merges the data from all the thread specific data blocks
> into the accumlators.
>
> Thoughts?

 But what would be the purpose of PROF'ing inside service-threads?

 Note that the only place where thread_safeness is required is in
 squidaio_thread_loop and squidaio_do_* funcs. All else is safe
 to use current PROF timers without mods as it runs within main
 thread. (partly its profiled already, like xmalloc calls, etc).

 If you want to know how long it takes to fulfill aio request,
 then you could start timer in main thread at aio schedule time
 and stop it in main thread at completion time.

 As most of stuff done in aio_do is longtime ops, cpu tick precision
 is not important there. Instead of knowing exactly how long it
 runs in OS, we get time between when we schedule op and when we
 notice its done. Less precision yes, but does it matter?
 Squidaio_thread_loop is so tight that question arises - what
 do you want to profile there? Would we want to make profing
 heavy just for the sake of being able to profile this single func?

 Profiling thread-switch overhead makes no sense, because you
 don't have one2one match of start and stop in principle. You
 never know what thread gets cpu next. Such timers will almost
 always show beans. To be general, you can't profile across
 IPC like in diskd, so why want to profile across threads.

 Well, to measure aio request OS service time we might want
 to add timer entries to request struct. When the request is
 in service, its exclusively owned by thread, then it could
 fill both start stamp and stop stamp, and then let main thread
 to calculate actual time diff.

 My main question is do we actually need to profile threads?

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Mon Oct 07 2002 - 02:47:54 MDT