Dear Henrik Nordstrom:
I had get the final result of comparing three version.In my new test
environment, the response time:
orig 14.227ms no_pipe 13.550ms pipe_patch 13.905ms
I have one questions below.
======= 2004-02-17 12:26:00 you wroted :=======
>On Tue, 17 Feb 2004, [GB2312] 夏洪涛 wrote:
>
>> 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.
>
>Yes.
>
>> 1. Dose poll/select never check FDs that represent opened files? They
>> can not poll the the disk I/O status themselves?
>
>poll/select can not check the readiness of local files. Such
>filedescriptors will always indicate ready for reading/writing even if
>such operations would block the process waiting for the disk.
I read the code, and found that in disk.c, function diskHandleWrite() and
diskHandleRead() had call commSetSelect() to poll the file descriptors.
Then if poll/select can not check the readiness of local files, the purpose
to call commSetSelect() is just divide write or read operation into pieces ,
so that other request can be processed. This can increase the throughput.Am I right?
>
>> 2. With high request ratio, the poll/select syscall seldom wait for
>> FDs,the pipe mechanism seems do bad to performance.Is it right?
>
>The pipe mechanism can potentially degrade performance somewhat in high
>request ratio as the context switching increases and more CPU is wasted,
>but I did not find any noticeable such drawbacks when testing this when
>the completetion pipe was implemented.
>
>The change I proposed in my previous email should address this by
>allowing fallback on batch processing on high loads at the expense of
>a risk of somewhat higher I/O latency.
>
>> I had test it roughly. The difference between two results seems not so
>> obvious.I'll test it more.
>
>Please tell more.
>
>Regards
>Henrik
= = = = = = = = = = = = = = = = = = = =
Best Regards
Xia Hongtao
[EMAIL PROTECTED]
2004-02-18
