On 02/28/2012 08:27 AM, David Dillow wrote:
> Is the purpose of this work to speed things up for the user, or for the
> developers? Your approach is correct for developers, since we're more
> likely to be making multiple dracut image with a warm cache. But users
> are more likely to hit the cold cache case.
Both users and developers. However, the cache must be controlled
(or known) for any measurement, else there is no way to attribute
the effects of any measured change: the cache effect could be much
larger than any improvement (or degredation). The easiest way
is to have a warm cache: discard the first run of a series because
of the unknown cache state.
The cold cache case can be approximated by:
# echo 1 > /proc/sys/vm/drop_caches
# time dracut ...
# echo 1 > /proc/sys/vm/drop_caches # each time!
# time dracut ...
but that path /proc/sys/vm/drop_caches is harder to remember
(and harder to get correct in a sudo!)
It is also harder to guarantee consistency on a machine that is
not otherwise idle.
Running dracut after updating kernel and/or drivers is likely
to hit a mixed cache: the updated stuff will tend to be hot,
the not-updated stuff probably will be cold.
--
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
