Bug 557609

what is in your prepared file?

Created attachment 331590 [details]
My current prepared file

Attached is my prepared file.  Currently my workaround is to add "nopreload" to the kernel cmdline.

you have a lot of files referenced in there and it tries to read them all - so it's not suprising it takes a while. 8 minutes is a bit much though.

Can you strace preload to see what it works on?

I have the same. I think that this came after the last update I installed 2 days ago which included a lot of KDE 4.3 files. Since then I notice a high cpu usage and a sluggish system. I killed the preload process and now the system is quiet again.

Sorry, but I've not had time to debug the issue yet.  I get around it by putting "nopreload" into /etc/sysconfig/bootloader for the kernel boot options.  I don't notice any degradation from not preloading, but did notice degradation when preloading was active.  I'll do an strace soon. One thing to note is that I never intentionally added files to the prepared file (don't even know how to do that).  The preload file was generated for me by install and day to day operation. Thanks.

Hi. 
I have same issues with preload. After boot my system is unresponsive for about 10 minutes and process "preload /var/cache/preload/prepared" consumes 40-80MB/s in iotop disk read. I think this slowness came after update to KDE 4.3.5.

Created attachment 350987 [details]
preload strace log

After slow preload (about 10 minutes) I restarted PC and straced preload process, but this time preload ended quick (about 2 minutes)

I can't make any sense out of the given data ;(

I always hoped someone would come with something more that would add the missing puzzle piece, but from what I have the only theory I have is that the filesystem is _very_ defragmented causing too many blocks to be read. And I'm not sure what I can do here. 

The only thing I can think of is adding a limit on how long it should run, so it stops e.g. after 2 minutes. Michael, what do you think? Any idea for a better limit of sanity?

The values in comment #7 strace log are completely bollocks.  Repeated fadvices
on files 10,11,12,13,17 with sizes and offsets being nonsensical:

E.g.:

370   1269684166.071359 fadvise64(13, 3422535680, 8388608, POSIX_FADV_WILLNEED)
370   1269684166.290542 fadvise64(12, 1653669888, 7274496, POSIX_FADV_WILLNEED)

So, file 13 at offset 3.4 GB, reading 8MB in size.  And so on ...

Unfortunately the strace doesn't show us which files are connected with those
file descriptors.  But files of such size can't possibly be interesting
files to preload.  Such files normally shouldn't be involved in the startup
process at all.  One guess would be for instance some log file gone wild,
that the preload tracer sees as being opened and hence like to read in
completely.

Instead of introducing an artificial limit on filesize (size > N --> don't
preload at all), or on read data size (ala always read in N MB max, per file),
I'd first like to know which files are the ones being so large.

But as stop-gap measure, I do think it makes sense to not preload, say,
8 MB per file (or to ignore all files > say 16 MB, this needs to be a bit
large so as to not ignore some of the very large shared libraries we have).

One other idea: if the above files are indeed logfiles or the like, then
they are probably opened O_WRONLY.  We can map such open calls to just
being stat()s, instead of causing a full read-in.

O_WRONLY is already ignored - it won't even be in the log file. So a size limit of what's read from a file has to work

I dropped preload for 12.1