I noticed that too. Furthermore I noticed that the results of the more
heavily loaded tests on the whole 2.4.0 series tend to be highly
variable (usually worse) if you started by moving the whole disk through
cache, e.g., fsck on a damaged filesystem.
> The reason for doing the benchmarks in the first place is that my 32MB P90
> at home really does perform noticeably worse with samba using 2.4 kernels
> than using 2.2 kernels, and that bugs me. I have no hard numbers for that
> machine (yet). If they will show anything extra, I will post them here.
> Btw, has anyone else noticed samba slowdowns when going from 2.2 to 2.4?
Again, yes, I saw that.
> Wow! You made it all the way down here. Congratulations! :-)
Heh. Yes, then I read it all again backwards. I'll respectfully bow
out of the benchmarking business now. :-)
It would be great if you could track the ongoing progress - you could go
so far as to automatically download the latest patch and rerun the
tests. (We have a script like that here to keep our lxr/cvs tree
current.) And yes, it gets more important to consider some of the other
usage patterns so we don't end up with self-fullfilling prophecies.
For benchmarking it would be really nice to have a way of emptying
cache, beyond just syncing. I took a look at that last week and
unfortunately it's not trivial. The things that have to be touched are
optimized for the steady-state running case and tend to take their
marching orders from global variables and embedded heuristics that you
don't want to mess with. Maybe I'm just looking at this problem the
wrong way because the shortest piece of code I can imagine for doing
this would be 1-200 lines long and would replicate a lot of the
functionality of page_launder and flush_dirty_pages, in other words it
would be a pain to maintain.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/