httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Lescohier <>
Subject Re: event mpm and mod_status
Date Mon, 07 Jan 2013 15:33:21 GMT
I see that event mpm uses a worker queue that uses a condition variable,
and it does a condition variable signal when something is pushed onto it.
If all of the cpu cores are doing useful work, the signal is not going to
force a context switch out of a thread doing useful work, the thread will
continue working until it's used up it's timeslice, as long as it doesn't
end early because it becomes blocked on i/o or something like that.  So, in
that case, the first thread to finish serving it's request and gets to
ap_queue_pop_something(worker_queue...) will get the item on the queue, and
it will have hot caches.  On the other hand, if only some of the cpu cores
are active, but the threads that are active are busy in the middle of a
request, the condition variable signal will wake up one of the idle
threads, the thread will be scheduled onto an idle core, and that thread
can start doing useful work.  That thread may have colder caches, but the
other cores were busy doing useful work any way, so it's worth activating
this thread on an idle core.

Also, if a worker thread is idle on waiting on
ap_queue_pop_something(worker_queue...), and the thread was unscheduled by
the OS process scheduler, when you wake it up again, the OS process
scheduler won't necessarily schedule it on the same cpu core it was on
before.  So, it won't necessarily have a warm cache after you wake it up
again.  You're only guaranteed a warm cache if the thread remains scheduled
by the OS.  The current queue/condvar implementation favors sending new
requests to threads that remain scheduled by the OS.

On Sat, Jan 5, 2013 at 9:37 AM, Jim Jagielski <> wrote:

> +1... a lot of little improvements can result in a BIG
> improvement.
> On Jan 5, 2013, at 8:34 AM, Graham Leggett <> wrote:
> > On 05 Jan 2013, at 2:05 AM, Stefan Fritsch <> wrote:
> >
> >> For 1., a better thread selection would definitely be a win. For 2.
> >> and 3., it is less obvious.
> >
> > +1.
> >
> > Just because in some cases a cache might not help, doesn't mean we
> shouldn't take advantage of the cache when it will help.
> >
> > Regards,
> > Graham
> > --
> >

View raw message