Comment 10 for bug 635834

So you are seeing additional "overhead" (including context switches
and cache misses) in what you are identifying as "uncached".

(aside)
Oddly, the --nodigest case is slower than if digests are calculated
for the "uncached" case. Likely from statistical noise ...

But I do not see any immediately apparent I/O stalls and waits anomaly
in the measured behavior. Sure there's waits in the measurement, all "uncached" I/O will
wait. But if I've misinterpreted the perf data, please point that out. What I
lack is some comparison point to calibrate my expectations so that
I can notice when some measurement is not within a typical range.

What _IS_ different about rpmdb I/O (from other I/O cases) is that RPM (and Berkeley DB)
goes to some lengths to ensure that data is written to disk.

While "rpm -qa" is largely a read operation, populating the memory pool cache
operation is a write operation. So you may wish to also control for the memory
pool cache by doing
    rm -f /var/lib/rpm/__db*
if you really want to measure the components of "rpm -qa" I/O more carefully.

You are making claims that rpm --rebuilddb is needed as part of normal maintenance
based on what you see as a normal user with a stop watch. The behavior needs
to be more carefully analyzed (imho) before that claim is justified (imho). Whether
it is true (or not) that --rebuilddb is needed I cannot yet say. But I know from a decade
of living without --rebuilddb for routine rpmdb performance maintenance that there's some other
piece of this puzzle that needs to be understood first.

Yes, the title "inefficient database disk reading" is misleading. *shrug* The behavior
needs to better characterized and understood first.