[NTLUG:Discuss] Disk I/O timings.

Steve Baker sjbaker1 at airmail.net
Tue Dec 4 22:40:22 CST 2001


This is driving me nuts...

I have a Linux program that does (essentially) this:

    open() a file for reading from a local ext2 file system on an IDE drive.

    fstat() in order to determine it's length

    mmap() to map it onto a chunk of address space

    cycle through that array reading each element and computing a checksum

    munmap() the address space

    close() the file.

Can anyone tell me when in that sequence of operations the transfer of
the data from the disk drive actually occurs?  (Presuming the file is not
in cache).

I've had a hard time measuring when it occurs. On one machine it appears
to be consuming a dozen milliceonds or more in the 'open' command and on
another machine, I see a similar amount of time being consumed when I cycle
through the array reading it.   I could believe the kernel would either
speculatively load the file into cache when it's 'open()'ed *or* wait until
the page fault from accessing the mmap'ed array triggered the first actual need
to know the contents of the file....but which is it?

The thing that makes measuring this hard (in my *VERY* large and complex
real application) is that I'm actually reading several files in parallel
using this technique - and also the caching of files into main memory
by the kernel makes all my testing highly non-repeatable.  I run my test once
and see long delays in file I/O - but the next time I run it, the file is
(presumably) still in cache so there are no significant delays in reading
it.

Is there a means to ask the kernel to erase the contents of it's disk cache?

I thought of un-mounting the drive that the file is on and re-mounting it - that
ought to invalidate the kernel's cache - but it's very inconvenient.  Is there a
better way?

I also realise that there is a RAM cache on the disk drive itself - does that
ever get filled speculatively by the drive (or the kernel) ?

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1 at airmail.net>   WorkMail: <sjbaker at link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net




More information about the Discuss mailing list