Kevin Littlejohn wrote:
> Ok, fair enough. Next question: How does the existing code deal
> with keeping order on requests?
Writes is handled by the aufs layer. See storeAufsWrite.
For reads there never is more than one outstanding request by Squid I
think.. but maybe we do have a problem there...
> Is it not acceptable to make the locking times as short as possible, and let
> the control thread wait? I mean, a lock/change a pointer/unlock sequence should
> be fast enough that it doesn't bother the control thread significantly, no?
Unless the lock holder has been blocked while holding the block yes.
Given that I quite easily can trigger the congestion on a single-CPU
machine it is not too unlikely...
Having the temporary queue does not cost much, and solves the problem.
If the queue gets locked for some duration, then the temporary queue
buffers pending requests which gets moved over in a large chunk when the
lock gets available.
What it does is basically to ensure that there will be a good queue
thruput even if there is some level of lock congestion. Without it one
could theoretically end up in a situation where there is an occilation
pattern between the main thread and the I/O threads, only allowing the
main thread to queue one request before being blocked again.. this way
the main thread is kept out of any such occilations, and there can only
be fights inbetween the I/O threads..
/Henrik
Received on Sat Mar 17 2001 - 06:28:17 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:38 MST