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

Andres Kroonmaa wrote:

> In this sense, even though squid has multiple threads, it is completely unsure if
> they ever run on separate cpus, including not only userspace but also all kernel
> space codepaths. Mostly because they are tightly related and same cpu can
> handle them all. Although unintuitive, it seems that best way to force other cpus
> into the scene is to detach threads from each other, use sort of loose interaction
> that does not allow same cpu to handle it straight. Like enqueue requests but
> not signal, instead let iothreads wake up through timed waits. This will cause
> latency and neccesitate scheduler pass, but would force OS to schedule these
> threads onto any free cpu. If single cpu is scarce, may even make sense.

A small note: async-io threads are intentionally requested to be
scheduled at system scope, not process scope. On most systems this makes
them candidates for "kernel threads".

> > And it is also true that I do not care. If it happens that two
> > cond_signal gets optimized down to a single signal I am equally happy
>
> That would be bad actually. means that instead of N threads only 1 thread would
> service N requests sequentially. As well we could use ufs then or single thread.

Well, not really. See other thread.

> I don't agree its implementation bug. First I thought so too. But its more like
> documentation bug, or api design bug. It kinda slipped through at initial api
> and stuck since then. Some systems now document warnings about races,
> some like linux simply and straightly say "must be used with mutex".
> To implement this cleanly would require more overhead than mutex. Why?

You are probably right. Better stay away from it and always protect cond
variables by a mutex. Does not make a whole lot of a difference for us
as in any event we most likely run long enough to unlock the mutex
before the signalled thread gets a chance to try to lock it. Most
certainly so on UP systems, and on SMP systems the spinlock of the mutex
will resolve the situiation nicely without a context switch (only costs
our users a little wasted mains power).

Regards
Henrik
Received on Sat Jan 04 2003 - 16:48:41 MST