Regardless of whether you choose to measure latency or
CPU load
if you vary the st_blksize as specified in the previous email,
you will not be able distinguish between the two values of
st_blksize due to the influence of other factors.
What are you talking about? How can one vary st_blksize or choose a
preferred value for it? Are you assuming that I am writing a kernel
driver? Why?
If you meant the actual request size, then I think that (1) none of us
have performed measurements and (2) as I stated, if no measurements
have been performed, and if the implementation allows it, standard
recommendations should be obeyed.
The behavior of fread() can be dubious for files
accessed
via NFS with respect to incomplete reads (ie EAGAIN). The
only solution to this is to use read().
Please detail this somewhat. NFS was one of the use-cases I mentioned
in the beginning (and I actively use it).
else address
the issues that arise from breaking the rules (i.e.
Breaking what rules?
K&R C and even CS1 choices (fread / fwrite), unless you have a reason
to break them... Not that I would be at that level...
You provide concrete proof that doing block sized
reads makes
any positive performance improvement and I'll implement block
sized reads and buffering.
You have already said you would accept patches and contributions for
this specific issues (a userspace cache) in past e-mails. Are you
retracting (or qualifying) the offer? In any case, you already have
the VIO layer, which certainly WFM -- my programs work.
Until you can show concrete proof I consider this
issue closed.
Which issue? I was merely discussing choices. And I was arguing that
YOUR VIO code is a GOOD thing. Uh, please don't remove it :)
Anyway, I have found sndfile to be an extremely valuable library.
-- Dan