[quagga-dev 3259] Re: [PATCH] non-blocking I/O from client daemons tozebra
Andrew J. Schorr
aschorr at telemetry-investments.com
Wed Apr 20 20:08:39 BST 2005
On Wed, Apr 20, 2005 at 07:52:42PM +0100, Paul Jakma wrote:
> both the normal synchronous and experimental queueing test cases hold
> up well to hammering.
> The vty is a bit laggy, like an ssh session to a far off host while
> you're downloading the latest release of your favourite OS, but it's
> still useable - more importantly, the daemon is still able to respond
> to IO and other events in a timely fashion.
I guess you could improve interactive response by decreasing the amount
of work done in each background call, but that time slice threshold is a
judgement call that should perhaps be tuneable by the configure script.
> If we defer the question of whether the timer aspect of the
> background thread is required, what do we think?
I generally think that we need background threads (or, alternatively,
a more general sense of thread priorities). At the moment, it's probably
much easier just to add the background threads (as you have done).
> If I can get this dusted, I can move on to making the queue helper
> api sensible. ;)
Well, I must confess that I am still not clear on why the whole workqueue
API is needed in addition to the background thread API. Have you tried
implementing the heavy-wq sample program just using background threads directly
without using the workqueue API? Is it really much worse?
P.S. A few questions about your patch:
1. Why this?
static unsigned int
cpu_record_hash_key (struct cpu_thread_history *a)
- return (unsigned int) a->func;
+ return ((unsigned long) a->func) & -1U;
2. In funcname_thread_add_background, why initialize trel to 0 before
checking for a non-zero delay value? Why not just set trel to 0 in an
3. Are the various "eek" printouts going to be in the final patch committed? :-)
4. In thread_fetch, is it possible to get to the select call if ready is
positive? Wouldn't we bail out a few lines above in this statement if
there were ready thread:
/* If there are any ready threads, process top of them. */
if ((ready > 0) && (thread = thread_trim_head (&m->ready)) != NULL)
return thread_run (m, thread, fetch);
To put it another way, if (ready > 0), is it possible for
thread_trim_head(&m->ready) to return NULL? If not, then the logic
below is a bit muddled...
More information about the Quagga-dev