Re: profiling aufs

On 7 Oct 2002, at 19:00, Robert Collins <robertc@squid-cache.org> wrote:
> On Mon, 2002-10-07 at 18:34, Andres Kroonmaa wrote:
>
> > But what would be the purpose of PROF'ing inside service-threads?
>
> Well for disk-servicing service threads, not much :}. For other forms of
> worker-thread scenario's, to establish what takes the most time.

 Do we have already some such scenarios? If no I'd suggest to postpone
 profiling threads until we have. We'll then also have better idea of
 how to do it.

> > 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).
>
> This isn't true. IF the worker threads do not use -any- common profiled
> calls, then it works, otherwise we may get xmalloc timings trashed (for
> example).

 Squid isn't threadsafe internally, so any common profiled calls
 are not allowed within threads anyway. That was my main point.
 If we'd call xmalloc from thread, squid wouldn't live an hour..

> > 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.
>
> Thats a different metric, and yes I agree :}.

 The only thing we'll add to our knowledge is time between aio
 completion and its noticing in main thread. To test that we
 could compile special squid with only 1 worker thread and use
 dedicated PROF timers for thread, with unaccounted time disabled.
 If you really suspect code path to suck, this test can be done.

> > My main question is do we actually need to profile threads?
>
> Today - no. In the future - maybe. IMO the queueing code can be
> generalised to support any blocking or cpu bound requests. This can be
> useful for things like content transformation. (Waaaay down the track).

 If we use threads only for something timeconsuming, then why we
 need tick precision? If we want to profile timeconsuming thing
 itself, then maybe it makes sense to support both threaded model
 and unthreaded, then we can easily profile the thing when unthreaded.

 Or, create special threaded version of profiler calls that have any
 required overhead and are specifically compiled with debug option.
 For main squid I'd rather like to optimise existing profiling to
 the point that it has least possible overhead in all cases.
 This is crucial for stuff that gets run over 100K times/second.

 PS. I don't really object doing it, just wait until real need
 arises. For now I'm more interested in hearing anyone saying that
 yess, this profiling thing has helped to make code better, and
 doesn't really slow squid down. I've had awfully little feedback
 y'know. ;)

------------------------------------
 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 - 05:25:09 MDT