[Iometer-user] Iometer changes (individually packaged) to run 'dynamo' on Fedora Core 4

[Christensen, R. K <ree...@in...>]

(Resend of previous message with changes individually packaged=20
into separate diff files.)

Hi,

I have been using Iometer on Fedora Core 4 and found the following=20
changes useful.=20

My starting point was the release
"iometer-2004.07.30.common-src.tar.gz".  (I could not find/access any
CVS on the Iometer SourceForge site, so I apologize if these changes are
old news.)

My development environment was:

  []# uname -r
  2.6.11-1.1369_FC4smp

  []# gcc --version
  gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)

  []# /lib/libc.so.6
  GNU C Library development release version 2.3.5, by Roland McGrath et
al.
  Compiled by GNU CC version 4.0.0 20050525 (Red Hat 4.0.0-9).
  Compiled on a Linux 2.4.20 system on 2005-05-30.

A seperate diff file, created with 'diff -Nurap /<old>/src /<new>/src'=20
is included for each of the following changes.

Compile Changes:
----------------
1. (iometer.zero)
   Changed function prototypes to use "function_name() =3D 0;" instead =
of
   "=3D NULL;" in order to repress compiler complaints like this:

  IOTarget.h:90: error: invalid pure specifier (only `=3D 0' is allowed)
before ";" token
  IOTarget.h:91: error: invalid pure specifier (only `=3D 0' is allowed)
before ";" token

2. (iometer.min_max)
   Renamed local min() and max() macros to __min() and __max().  One of
the
   common libraries had these macros and the definitions conflicted.


Useability Changes:
-------------------
1. (iometer.odir)
   Added O_DIRECT attribute to file open() command calls, otherwise the
reads and writes to disks hit the Linux kernel caching and do not
reflect I/O rates to disks under test.=20

2. (iometer.nonz)
   Fill the write buffer with non-zero data.  Having "interesting" data
can have an effect on system performance.  (Really!  It does, try it.)

3. (iometer.port)
   Added a printf notice when a port connection is made.


Correctness Changes:
--------------------
1. (iometer.jiff)
   CPU utilization measurements are not being done correctly for 2.6
Linux
   kernels.  (In particular, the Fedora Core 4 kernel
2.6.11-1.1369-FC4smp.)
   Changes made to fix this problem:

   - Added an entry CPU_JIFFIES to store the total number of jiffies
that          =20
     have been executed in the cpu.  This number is required as a
     denominator in order to calculate the percentage value of other
jiffies=20
     counts. It includes Idle and IOWait jiffies.

   - Tweaked fscanf calls that read /proc/stat

2. (iometer.blks)
   Caused that a failure to get BLKGETSIZE64 will instead try
BLKGETSIZE.
   Better chance at getting the correct device size.

3. (iometer.rand)
   Avoided use of modulo (%) operator by modifying Rand() function.
Turning=20
   on random accesses in Iometer/dynamo was causing floating point
exception
   faults very reliably.  Compiled dynamo with -g and set 'ulimit -c
   unlimited' in order to get core file, and got some info from gdb:

   (gdb) where
   #0  0x00c8540b in __umoddi3 () from /lib/libgcc_s.so.1
   #1  0x08050f0a in TargetDisk::Seek ()
   #2  0x080501fe in Grunt::Do_IOs (this=3D0xb7f90008) at =
IOGrunt.cpp:1251
   #3  0x08050534 in Grunt_Thread_Wrapper (grunt=3D0xb7f90008) at
IOGrunt.cpp:992
   #4  0x00b3eb80 in start_thread () from /lib/libpthread.so.0
   #5  0x009c0dee in clone () from /lib/libc.so.6

   I believe the __umoddi3() call is the "%" or modulo operator inside
of this call function:
         ((TargetDisk *) targets[target_id])->Seek( access_spec.Random(
                 access_percent,
		    (unsigned int)targets[target_id]->Rand() % 100 ),
size,
                 user_alignment, user_align_mask );

  Found a mail thread on a postsql site that pointed out the tricky
numeric nature of modulo operator:
     http://archives.postgresql.org/pgsql-general/2005-05/msg01187.php

And this link:
     www.nabble.com/Re:-Remainder-(-)-operator-and-GCC-p1412329.html