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

From: Andres Kroonmaa <andre@dont-contact.us>
Date: Sun, 05 Jan 2003 13:55:34 +0200

On 5 Jan 2003 at 0:47, Henrik Nordstrom wrote:

> 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".

 more precisely - this makes them literally kernel threads. But this doesn't mean that they
 run on separate cpus concurrently always when possible. System has few hundred kernel
 threads and only few cpus. Each cpu is handling several threads, switching between
 them at most suitable points. Two kernel threads belonging to same process will be
 serviced by same cpu if, while running one, code makes thread switch to other. Then cpu
 has needed switch details handy and there's no need to make expensive scheduling pass,
 so these 2 threads will be run sequentially by same cpu.

 I'd imagine, that when squid schedules IO to its threads, all scheduling happens with
 same cpu. But threads returning from blocking syscalls are highly likely to return
 running on other cpu. Thats because they necessarily are started from OS scheduler,
 and if main thread is busy, there's not much choise.
 Today thats not much of an issue, but if we decide in future to blast few hundred thread
 jobs per second, must keep in mind that most of it can be happening with same cpu.
Received on Sun Jan 05 2003 - 03:41:55 MST

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