Re: [SQU] multiprocessor machines

Adrian Chadd wrote:

> What people have to realise is that the mechanics behind a poll() loop
> really don't scale, and even though it can be made to scale better,
> it will take a lot of work. The more CPU you throw at it will make
> the code run better, but the main influencing factor behind the behaviour
> of poll() is the network traffic patterns, not the CPU you throw at it.
> I've kernel-profiled squid boxes spending 50% of their time in a big
> poll() loop in the kernel..

I read (on Kernel Traffic, many moons ago) of a neat method to get
around this. In the simplest case, you have two threads, both of which
are in poll(). One thread takes care of the few file descriptors that
are really busy (the overhead from poll() is kept low by only having a
few file descriptors on the list), and one takes care of the rest that
are mostly idle (the overhead from poll() is kept low by not being
called very often). This could be extended to additional threads in an
obvious way.

The benefits of this approach would be that the idle/busyness of HTTP
connections is pretty predictable, you'd get SMP support "for free", and
it would work with current kernels that don't have some notional poll()
successor implemented. The drawbacks would be that it would perform
badly in benchmarks (where all connections would tend to be the same),
and that I can see it being extremely challenging to implement.

Adam

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html