Re: removing an ext2fs file forces disk activity

[Jon Arney]

Hi,

At the risk of being too abrasive, I'd like to weigh in on the
issues of performance characterization I saw during the course
of this thread and hope to clear up a potential misunderstanding.
I begin by examining an argument presented on CPU utilization and
move on to provide what I believe is a _slightly_ more rational
approach to capturing a relative performance characterization
of the Hurd.

>From Ludovig on his Hurd i386:
> I noticed another one two. :) It's actually more a performance issue. For
> instance, when unpacking a tarball, "ps aux | head" shows that the ext2fs
> server starts consuming most of the CPU time (more than 30% on my 350MHz proc
> machine). This happens also whith the pflocal server sometimes.

>From Niels on his Linux Sparc station 4:
> The numbers depend a lot on the actual hardware, and the relative
> speed of the cpu and disks, I think. I just tried extracting
> gcc-3.0.4.tar (note, no .gz, unzipping would soak up most of the idle
> time). top reported that the tar process consumed about 60% cpu, and
> an overall CPU usage of about 10% user, 50% system and 40% idle.

>From Thomas Bushnell:
> So on the Hurd, you had 30%, and on Linux, you have 60%?=20=20

Hmmm.  I don't thing we've accurately characterized the relative
performance of the Hurd vs. Linux.  There appear to be three
problems here.

Firstly, %cpu time is an instantaneous rate of cpu consumption
which varies widely from time to time depending on sample interval.
What we're really interested in, I think, is the integral of %cpu
over the lifetime of a process.  That is, the amount of time
(on behalf of the process both user and system) consumed.
In other words, if I take 10% cpu time for 10 seconds, that is
roughly equivalent to taking 100% cpu time for 1 second.  The
amount of system resource required to complete a task of known
parameters is the same.  Of course, there may be particular
scheduling contstraints which make the former more desirable
in some circumstances over the latter, but I leave that issue
alone for the purposes of discussion.  An equivalent metric
for disk I/O is the transfer rate.  That is, the number of
bytes successfully transferred to/from a disk device or
filesystem per unit time spent on said transfer.

Secondly, the above comparison compares two very _different_
machines with different system parameters.  A relative performance
characterization of 30% vs 60% is essentially meaningless for
capturing the differences between Hurd and Linux performance.

Finally, high CPU utilization is usually a GOOD sign during
I/O intensive operations because it indicates that the CPU
is not spending lots of time waiting on the I/O but is instead
being employed to good use.  i.e.  if the CPU utilization is
high this generally indicates that the system is not waiting
awfully long for I/O operations to be completed (at least in
cache).  The system's performance should be gated by the
fastest individual component of the system (usually the CPU
and front side bus).

This is why I initially suggested that some relative (and
independently verifiable) performance characterizations be
gathered for the Hurd, lest we be fooled into believing
that the Emperor is wearing clothes.

Such performance data might also ultimately be useful in tracking
the progress of the Hurd over time so that we can see what the
changes we make are doing in terms of performance of various
subsystems (io/network/...).

Here's a start at some performance statistics.  I suggest that
if anyone else is interested in characterizing the system that
they begin with downloading bonnie:

http://www.textuality.com/bonnie/download.html

Run it under the Hurd and Linux (on the same box) and send the results
to me.  To ensure that the numbers are clear and consistent, please
make sure the bonnie program is run with no other applications
active on the system (minimize interference from other applications).
Also, please include the type, speed and amount of L1 and/or L2 cache
present on your system and the type of drive with on-drive cache
available (Linux dmesg should show you this).

I can then compile the results and present them in a clear
and understandable form.

I realize that 'bonnie' is not the be-all/end-all of performance
characterization tools, but is a better tool to begin with than
'tar' and 'top' in terms of consistency of measurement and use.

----------------------------------------------------------------------
Machine: Compaq Pentium III 850 Mhz
256 Kb L1 cache

Under Linux-2.4.17 
hdc: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63,
UDMA(33)

File './Bonnie.1126', size: 104857600
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done...
              -------Sequential Output-------- ---Sequential Input--
--Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
/sec %CPU
          100 10464 91.5 140505 97.4 141525 99.5 11226 97.7 445682 100.1
21369.7 96.2

Under Hurd-0.2
Transfer mode unknown

File './Bonnie.94', size: 104857600
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
              -------Sequential Output-------- ---Sequential Input--
--Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block---
--Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU 
/sec %CPU
          100  1164  3.6  1375  1.0  1087  5.6  1508  5.3  3104  3.9
159.5  4.1


After examining the numbers, I think you will join me in appreciating
the relative performance differences between the Hurd's ext2fs and
Linux's ext2fs implementations.  For the sake of completeness, it 
would be interesting to examine the numbers under FreeBSD and other
similar systems.  The more numbers we get, the better understanding
we will have of the performance of the Hurd relative to other
O/S implementations.  This may lead ultimately in the direction of
altering the implementation to the betterment of the system.

Note that I have not yet begun to investigate the (many) reasons for
the performance disparity.  First of which I would like to attempt
to examine is the transfer mode (DMA/UDMA/PIO) that Mach is using.
This tends have a tremendous impact on disk throughput leaving
filesystem implementation issues aside for the moment.

That's all for now.  I'll follow up if any conclusions or additional
data become available.

Jonathan S. Arney
Software Engineer
jarney1@cox.net
------------------------------------------------------------------------
Some people call me a nihilist.
That would be true except I don't believe in nihilism.
------------------------------------------------------------------------