lkml.org 
[lkml]   [2001]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Benchmarking 2.2 and 2.4 using hdparm and dbench 1.1
On Wed, 3 Jan 2001, Daniel Phillips wrote:

> Tobias Ringstrom wrote:
> > 3) The 2.2 kernels outperform the 2.4 kernels for few clients (see
> > especially the "dbench 1" numbers for the PII-128M. Oops!
>
> 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.

Yes, they do seem to vary a lot.

> 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.

I was thinking about an automatic test, build, modify lilo, reboot cycle
for a while, but I don't think it's worth it. Benchmarking is hard, and
making it automatic is probably even harder, not mentioning trying to
interpret the numbers... Probably "Samba feels slower" works quite well.
:-)

But then it is even unclear to me what the vm people are trying to
optimize for. Probably a system that "feels good", which according to
myself above, may actually be a good criteria, although a but imprecise.
Oh, well...

> 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.

How about allocating lots of memory and locking it in memory? I have not
looked at the source, but it seems (using strace) that hdbench uses shm to
do just that. I'll dig into the hdbench code and try to make a program
that empties the cache.

/Tobias

-
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/

\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.123 / U:2.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site