Re: [squid-users] Squid Performance Issues - reproduced

Andres Kroonmaa wrote:

> > The problem is how to find out. We cannot reliably tell if an I/O
> > request will block or not, but in quite many cases it won't because of
> > os level caching already having the needed metadata cached in memory.
>
> Yes, for reads sure. But writes? Unless they are raw unbuffered writes,
> all that happens is buffer copy to kernel space. If its full, write would
> return with eagain. Only then perhaps pass it on to threads.

As it is today threads are not used for writes. See async_ufs.h

> yes, it seems. Why I thought of pipe is that its sort of cond_signal in OS,
> thats buffered, ie does not cause immediate thread switch, but would
> require scheduler pass. Ie. allow other cpu to kick in more likely. But it
> would cause iothreads to wake up later. Seem we have to make choise,
> whether no latency and iojobs start quickly but we waste main thread
> cpu-time, or we have latency but main thread has more time to run.
> By threading style, we should not care, but we do because our main
> thread cannot utilise MP, it runs on single cpu only.

I think a single signal from main, rest in the I/O threads design would
be quite sufficient here, but some benchmarking may be needed to
determine the impact on scheduling by delaying the signals.. (i.e. main
thread unblocking multiple threads for scheduling, vs I/O threads
unblocking one additional thread when scheduled).

My gut feeling is that there won't be much difference in a real-life
workload.

>
> btw, interesting bit in linux manpage. They claim that if multiple threads
> possibly sleep on cond_wait, cond_signal is marginally faster only "if it
> can be proved that exactly 1 thread needs to be awaken only. In doubt,
> use pthread_cond_broadcast." I read this so that if we need to awake
> >1 thread, we'd better use cond_broadcast. Not seen such advise before.
> Upon broadcast, all threads must respin on mutex, who miss the var
> see spurious wakeup. Sounds like quite some waste of cpu. dunno.

I don't think the author of that man page has considered the situation
where there is considerably more threads waiting on the cond than needed
to fulfill the signalled condition.

How I read the comment:

Using cond_signal requires that you know what you are doing to not end
up with too few threads signalled.

Using cond_broadcast is always a safe bet, and thus if you are unsure
use cond_broadcast.

> No, spurious wakeups happen on every kill signal, vm faults, etc. I have
> no idea how to distinguish spurious wakeup from our signaling.

Ah. well. But my understanding is that on Linux there won't be many such
events as the threads are quite isolated from each other when it comes
to signals..

> And currently, old thread can't actually grab anything, because req queue
> is protected by mutex.

We are already inside the mutex here. Don't see the point.

> these cpu counters are hardware, like eax. On SMP systems they tick in
> sync - cpus use same clock. So they are available always, they are the
> same value no matter what cpu. Only thing to solve is shared structs.

Great!

Regards
Henrik
Received on Sun Jan 05 2003 - 12:05:43 MST