Re: [Iometer-user] Iometer changes to run 'dynamo' on Fedora Core 4

[Ming Z. <mi...@el...>]

Hi Christensen

Thanks a lot for this and I will check them and try to merge or give u
my feedback.

iometer cvs can find at http://sourceforge.net/cvs/?group_id=3D40179. not
sure why u could not access it. my last time access was ok.

also recently i switch to use svn for iometer. u can get code from
svn://svn.berlios.de/svnroot/repos/iometer.

ming


On Wed, 2006-03-15 at 17:15 -0800, Christensen, ReedX K wrote:
> Hi,
>=20
> =20
>=20
> I have been using Iometer on Fedora Core 4 and found the following
> changes useful.=20
>=20
> =20
>=20
> My starting point was the release
> "iometer-2004.07.30.common-src.tar.gz".  (I could
>=20
> not find/access any CVS on the Iometer SourceForge site, so I
> apologize if these
>=20
> changes are old news.)
>=20
> =20
>=20
> My development environment was:
>=20
> =20
>=20
>   []# uname -r
>=20
>   2.6.11-1.1369_FC4smp
>=20
> =20
>=20
>   []# gcc --version
>=20
>   gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
>=20
> =20
>=20
>   []# /lib/libc.so.6
>=20
>   GNU C Library development release version 2.3.5, by Roland McGrath
> et al.
>=20
>   Compiled by GNU CC version 4.0.0 20050525 (Red Hat 4.0.0-9).
>=20
>   Compiled on a Linux 2.4.20 system on 2005-05-30.
>=20
> =20
>=20
> A diff file is attached that has the code tweaks made for the
> following
>=20
> changes.
>=20
> =20
>=20
> =20
>=20
> Compile Changes:
>=20
> ----------------
>=20
> 1. Changed function prototypes to use "function_name() =3D 0;" instead
> of
>=20
>    "=3D NULL;" in order to repress compiler complaints like this:
>=20
> =20
>=20
>   IOTarget.h:90: error: invalid pure specifier (only `=3D 0' is allowed=
)
> before =E2=80=9C;=E2=80=9D token
>=20
>   IOTarget.h:91: error: invalid pure specifier (only `=3D 0' is allowed=
)
> before =E2=80=9C;=E2=80=9D token
>=20
> =20
>=20
> 2. Renamed local min() and max() macros to __min() and __max().  One
> of the
>=20
>    common libraries had these macros and the definitions conflicted.
>=20
> =20
>=20
> =20
>=20
> Useability Changes:
>=20
> -------------------
>=20
> 1. Added O_DIRECT attribute to file open() command calls, otherwise
> the reads and=20
>=20
>    writes to disks hit the Linux kernel caching and do not reflect I/O
> rates to the
>=20
>    disks under test.=20
>=20
> =20
>=20
> 2. Fill the write buffer with non-zero random data.  Having
> "interesting" data can have
>=20
>    an effect on system performance.  (Really!  It does, try it.)
>=20
> =20
>=20
> =20
>=20
> Correctness Changes:
>=20
> --------------------
>=20
> 1. CPU utilization measurements are not being done correctly for 2.6
> Linux
>=20
>    kernels.  (In particular, the Fedora Core 4 kernel
> 2.6.11-1.1369-FC4smp.)
>=20
>    Changes made to fix this problem:
>=20
> =20
>=20
>    - Added an entry CPU_JIFFIES to store the total number of jiffies
> that have
>=20
>      been executed in the cpu.  This number is required as a
> denominator in
>=20
>      order to calculate the percentage value of other jiffies counts.
> It
>=20
>      includes Idle and IOWait jiffies.
>=20
> =20
>=20
>    - Tweaked fscanf calls that read /proc/stat
>=20
> =20
>=20
> 2. Caused that a failure to get BLKGETSIZE64 will instead try
> BLKGETSIZE.  Better=20
>=20
>    chance at getting the correct device size.
>=20
> =20
>=20
> 3. Avoided use of modulo (%) operator by modifying Rand() function to
> pass in modulo
>=20
>    value and then use fmod(). =20
>=20
> =20
>=20
>    Turning on random accesses in Iometer/dynamo was causing floating
> point exception
>=20
>    faults very reliably.  Compiled dynamo with -g and set 'ulimit -c
> unlimited' in order
>=20
>    to get core file, and got some info from gdb:
>=20
> =20
>=20
>    (gdb) where
>=20
>    #0  0x00c8540b in __umoddi3 () from /lib/libgcc_s.so.1
>=20
>    #1  0x08050f0a in TargetDisk::Seek ()
>=20
>    #2  0x080501fe in Grunt::Do_IOs (this=3D0xb7f90008) at
> IOGrunt.cpp:1251
>=20
>    #3  0x08050534 in Grunt_Thread_Wrapper (grunt=3D0xb7f90008) at
> IOGrunt.cpp:992
>=20
>    #4  0x00b3eb80 in start_thread () from /lib/libpthread.so.0
>=20
>    #5  0x009c0dee in clone () from /lib/libc.so.6
>=20
> =20
>=20
>    I believe the __umoddi3() call is the "%" or modulo operator inside
> of this call
>=20
>    function:
>=20
>          ((TargetDisk *)
> targets[target_id])->Seek( access_spec.Random( access_percent,
>=20
>                  (unsigned int)targets[target_id]->Rand() % 100 ),
> size,
>=20
>                  user_alignment, user_align_mask );
>=20
> =20
>=20
>   Found a mail thread on a postsql site that pointed out the tricky
> numeric nature of=20
>=20
>   modulo operator:
>=20
>      archives.postgresql.org/pgsql-general/2005-05/msg01187.php
>=20
>      www.nabble.com/Re:-Remainder-(-)-operator-and-GCC-p1412329.html
>=20
> =20
>=20
> =20
>=20
> =20
>=20
>=20