Re: 2.4.19pre9aa2

>> More benchmarks on quad Xeon at:
>> http://home.earthlink.net/~rwhron/kernel/bigbox.html

> Just a note, watch the "File & VM system latencies in microseconds"
> lmbench results, the creat become significantly slower, I'm wondering if
> that's due the removal of the negative dcache after unlink. I think it's
> still a global optimization (infact I think some of the dbench records
> are also thanks to maximzing the useful cache information by dropping
> immediatly negative dentries after unlink), but I wonder if the
> benchmark is done in a way that generate false positives. To avoid false
> positives and to really benchmark the whole "creat" path (that includes
> in its non-cached form also a lookup in the lowlevel fs) lmbench should
> rmdir; mkdir the directory where it wants to make the later creats
> (rmdir/mkdir cycle will drop negative dentries in all 2.[245] kernels
> too).  Otherwise at the moment I'm unsure what made creat slower between
> pre8aa3 and pre9aa2, could it be a fake result of the benchmark? 

I'll send you the 25 samples each of pre9aa2 and pre8aa3 off list.
All of the non-averaged lmbench results are currently at:
http://home.earthlink.net/~rwhron/kernel/lmball.txt

Some lmbench tests vary a lot.  The 0k and 10k creat tests were
pretty consistent for these two kernels.

Other consistent tests that showed notable improvement were context
switching at 8p/16K, 8p/64K, and 16p/16K.  The 16p/64K context switch
latency became inconsistent and higher on pre9aa2.

fork latency was consistent and improved by 10%.

> The pipe bandwith reported
> by lmbench in pre9aa2 is also very impressive, that's Mike's patch and I
> think it's also a very worthwhile optimizations since many tasks really
> uses pipes to passthrough big loads of data.

Yeah, that is impressive.

Glancing through the original lmbench logfiles, there are some results
that aren't in any report.  creat 1k and 4k, and select on various 
numbers of regular and tcp file descripters.  

-- 
Randy Hron