[systemd-devel] readahead-replay seems to not be doing anything.
Kok, Auke-jan H
auke-jan.h.kok at intel.com
Mon Feb 11 10:52:30 PST 2013
On Mon, Feb 11, 2013 at 2:34 AM, Gary van der Merwe <garyvdm at gmail.com> wrote:
> Hi all.
>
> This is my first post to this list, so I just want to say I thank you
> too all those
> who wrote systemd.
>
> systemd-readahead-replay does not seem to be doing what it should.
>
> Bootchart with readahead-[replay|collect] enabled:
> http://www.garyvdm.co.za/bootchart-20130211-1328.svg
>
> Output of `/usr/lib/systemd/systemd-readahead analyze /.readahead` :
> http://www.garyvdm.co.za/systemd-readahead-analyze
>
> There is no output in `journalctl -u systemd-readahead-replay.service`
>
> Bootchart with readahead-[replay|collect] disabled:
> http://www.garyvdm.co.za/bootchart-20130211-1409.svg
>
> Note that both my root & home partitions are btrfs with
> options=defaults,noatime,compress=lzo.
>
> If you compare the bootcharts, you see that there is very little io reads when
> systemd-readahead-replay starts. (Do systemd-readahead-replay reads not show in
> bootcharts by design?)
the replay thread should be relatively short-lived, and theoretically
should run for about (readaheadvolume / hdd_speed) in time.
> Am I correct in thinking that systemd-readahead-replay is not doing what it
> should?
absolutely. Or at least, something is preventing it from working properly.
> How can I debug why it is not working?
unfortunately, it's hard to debug this. I've attached strace -tt to
-replay and get an idea of the timestamps of each fadvise() calls.
Also, I see you're using btrfs. I've noticed bad btrfs performance
with readahead and this reminds me that read_ahead_kb was horribly
mistuned for btrfs - I think we included some fixes for it but I don't
know whatever happened to those tunes.
compression may also be an extra factor.
what kind of drive does that system have?
Cheers,
Auke
More information about the systemd-devel
mailing list