lkml.org 
[lkml]   [1999]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: bad lmbench numbers for mmap
Date
> So do you want me to change it to do reads instead?
>
> Another thing I could do is to factor out the cost of mmap by running two
> experiments:
>
> a) repeatedly read a region which is already mapped
>
> b) repeatedly mmap & read & unmap.
>
> In theory, b - a == mmap+munmap cost. However, if the munmap causes the
> caches to get flushed, or if the new mapping is somewhere else, then cache
> misses start skewing the results.

While you're at it, could you please change the lmbench script to put the
real version number into the results file and possibly refuse to make a
summary from different versions?

Current lmbench script even in 2alpha11 prints out 1.1, that's why I told
Linus my lat_mmap result from 2.1.103 is probably output from older lmbench,
but probably it is not (I'll have to find hardware which will allow me to
run 2.1.103 to test it again). I think this is important especially when the
tests change so much during the time.

Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.2.5 on a sparc64 machine (3958.37 BogoMips)
___________________________________________________________________

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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