Re: [SQU] multiprocessor machines

From: Adrian Chadd <adrian@dont-contact.us>
Date: Tue, 2 Jan 2001 15:42:42 -0700

On Wed, Jan 03, 2001, Colin Campbell wrote:
> Hi,
>
> Are we not adding a lot of complexity to squid to take advantage of
> SMP? Splitting threads across multiple processors can slow things down if
> you startrelying on mutexes or sharing data because of (processor) cache
> coherency problems requiring memory accesses all the time, flushing the
> cache etc.
>
> Why not something simpler like adding SO_REUSEADDR to the socket creation,
> running multiple squids (eg one per cpu), splitting the cache between the
> squid instances (eg with 2 cpus and 4 disks have squid0 on cpu0 using
> disks 0,1 and squid1 on cpu1 using disks 2,3) and treating them all as
> peers?
>
> Has anyone tried something like this?
>
> Taking this one step further would require the squids being able to
> operate on one cache. I haven't deepe enough knowledge of squid's
> internals to know how feasible this would be. Comments?

Thats what I'm aiming for. Since squid 'caches' disk data itself
we can't guarantee coherence. The modio stuff is aimed at supporting
this as a "side effect".

With a kernel-level FS which handles multiple processes accessing objects
and caching "hot" object information in memory, squid can then be run in
the configuration you've mentioned.

Some "magick" will be needed for stuff like ICP and the HTTP socket to
"balance" it across multiple squid processes, but .. ;-)

I'm glad someone mentioned it.

Adrian

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html
Received on Tue Jan 02 2001 - 15:44:57 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:57:19 MST