Hi Mulyadi, You are quite right. There are many things which can affect the tests. I think the most import two factors are (1) how files are accessed, e.g. sequentially or randomly, (2) which buffer cache and readahead algorithms are used.
I've read Fengguang Wu's work some where. Basically readahead algorithms can guess file access patterns. For sequential access, readahead can bebefit a lot. But for random access, readahead algorithms cannot guarantee to retrieve the proper sectors, which can have extra performance overhead. My assumption is that readahead can give overhead for random access pattern when system memory is limited. My tests read a file randomly. forgot about to mention it in my first email. sorry about this. I'm doing these kind of tests to see when you can benefit from buffer cache and readahead, and when buffer cache and readahead can hurt you. Your article seems interesting. Need to read it closely. Thanks! Fei On Dec 11, 2007 3:33 PM, Mulyadi Santosa <[EMAIL PROTECTED]> wrote: > Hi... > > However for my testings, the performances are about the same regardless > if > > the system has more memory (larger than the file size) or not. I can't > quite > > understand this. Can anyone help me with this? I'm using kernel 2.6.18. > > It will be a quite long answer if you need details. In essence, it > entirely depends on how you did the test, what background processes > that run, your L1/L2 cache size, the effective page cache replacement > algorithm and so on. > > One thing that has great impact is the way you read the file. How did > you do it? sequentially? or read N kilobytes then skip M kilobytes? > backward? Also, don't forget about the I/O scheduler you currently > use... it may have impact on certain degree. > > To give you a view on how complicated the I/O test regarding this > issue, take a look on my article: > http://www.samag.com/documents/s=10101/sam0616a/0616a.htm > > Actually it talks about Fengguang Wu's Adaptive Read-ahead, but > generally it also cover about file I/O operation in Linux. > > I'm sorry if my answer doesn't really clear your doubt.... > > regards, > > Mulyadi. >
