Reprofile when /lib/modules is updated

[Jérôme]

Binary package hint: sreadahead

The /etc/cron.monthly/sreadahead cron task is triggering the sreadahead pack file regeneration.

However, if you imagine there is a kernel update just after the monthly regeneration, then the system boot process will not reach its maximum speed before one month.

I attached a cron script which provide the below features:
- trigger regeneration if there is a major library update (like /lib/module/2.6.31-12-generic instead of /lib/module/2.6.31-11-generic) which has an impact on the boot process
- trigger regeneration after 1 month if no major update occured
- prevents to trigger regeneration more than once a week

This script could be placed in the /etc/cron.daily/ directory and could replace the current /etc/cron.monthly/sreadahead

ProblemType: Bug
Architecture: amd64
Date: Fri Oct 9 16:59:48 2009
DistroRelease: Ubuntu 9.10
Package: sreadahead 1.0-4
ProcEnviron:
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-12.41-generic
SourcePackage: sreadahead
Uname: Linux 2.6.31-12-generic x86_64
XsessionErrors:
 (gnome-settings-daemon:1172): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (gnome-settings-daemon:1172): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (polkit-gnome-authentication-agent-1:1224): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (nautilus:1217): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed

[Matt Zimmerman (mdz)]

sreadahead includes a dpkg trigger which will cause profiling to be repeated if files in /etc/init or /etc/init.d are changed. This could be trivially extended to include /lib/modules as well, if that is an important bit of readahead data, by adding it to debian/sreadahead.triggers in the source package.

[Jérôme (jerome-bouat)]

In this case, the monthly cron script is currently harming the boot process.

Indeed it could trigger again a profiling a few day after the profiling triggered by the dpkg trigger.

[Jérôme (jerome-bouat)]

I added the dpkg trigger in case of change in /lib/modules.

[Scott James Remnant (Canonical) (canonical-scott)]

I'm actually going to do something even more interesting. ureadahead will always reprofile and resort the pack after every boot. Yes, this will include any blocks read last time and not this time, but not any files read last time and not this time, so the pack will only grow slowly - and that'll be offset by the fact it'll always be up to date wrt disk segmentation.

(basically we'll always enable tracing, then always read, and ignore our own pid when we read back the trace file <g>)

We'll keep a record of the original pack file size, and throw it away if it goes over 25% of original size or something.

[Jérôme (jerome-bouat)]

What would be the slowdown added by the tracing ? 10 % slower ?

[Scott James Remnant (Canonical) (canonical-scott)]

Marking the sreadahead task as Invalid since that package isn't in Ubuntu anymore - this is still an open bug on ureadahead.

The tracing overhead for an online retracing is basically zero. Offline retracing like we do know can slow down the boot by over three or four times!