Thank you for your reply! I still had some questions below. :-)
>On Mon, 16 Feb 2004, [GB2312] ÏĺéÌÎ wrote:
>
>> I had take a experiment today, and fund that the pipe mechanism is not
>> necessary for aufs.
>
>It is a tradeoff for aufs to not degrade heavily when there is only little
>work.
Dose this mechanism can improve the throughput of squid ?
btw.
I had done some test to measure the MAX throughput of squid. Then I got a
interesting result: The result will be effected by the order of load which
we emluated.
If the load increase step by step: we will get a peak point, after this
point, the squid will not work well. This peak point might be the MAX throughput
of squid.
But now we do it in another order, we give a little bigger load than the
peak firstly. the squid can not work well. Then we wait for all tcp connection
closed, and give the load a little less than the peak load, we found the squid
still can not work well. Did the MAX throughput decrease? In all of the store
types, whichone has the best throughput? aufs or diskd?
>
>> I know that the pipe is the mechanism to force the main process to
>> resume when an disk I/O operation have completed. but I had inspect the
>> source code, found the pipe was set non- blocked. and the callback
>> function of the pipe just read characters from the pipe. Then how dose a
>> non-blocked pipe force the main process to resume?
>
>The worker thread writes a single character to this pipe when done. This
>signals the poll/select loop that something has happened allowing the disk
>I/O status to be polled. This all happens within the main loop. The pipe
>is just there as an element which can be included in the main poll/select.
Oh, I get it. Do you mean: When poll/select syscall wait on the ready FDs,
the pipe can wake up poll/select syscall, and enter another loop. At each loop,
storeDirCallback() will be called first. It will poll the disk I/O status.
Then if I'm right, I had such questions:
1.Dose poll/select never check FDs that represent opened files? They can
not poll the the disk I/O status themselves?
2.With high request ratio, the poll/select syscall seldom wait for FDs,the
pipe mechanism seems do bad to performance.Is it right?
>
>Without it the main thread does not notice the I/O worker thread have
>finished the operation and I/O status will not be polled until poll/select
>timeout or network activity.
>
>It is quite likely the pipe activity can be further optimized to only
>signal completetion via the pipe when required to break the above
>mentioned degration. Maybe such simple change as the attached patch
>improves your results? (please test)
I had test it roughly. The difference between two results seems not so
obvious.I'll test it more.
>
>Regards
>Henrik
= = = = = = = = = = = = = = = = = = = =
Received on Tue Feb 17 2004 - 04:28:55 MST
This archive was generated by hypermail pre-2.1.9 : Mon Mar 01 2004 - 12:00:04 MST