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.
> 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
Received on Tue Feb 17 2004 - 04:27:07 MST
This archive was generated by hypermail pre-2.1.9 : Mon Mar 01 2004 - 12:00:04 MST