You're quite correct, the phase in which the throughput goes very low is
open()ing all the files - there's little I've been able to do to speed
that up.
The current proposal is to drop the requirement to do that by adding a
kernel syscall that lets us populate the page cache by inode number,
I just created a test user and reprofiled with that one.
** Attachment added: ureadahead-dump-test.txt.gz
http://launchpadlibrarian.net/36502101/ureadahead-dump-test.txt.gz
--
throughput goes very low after a first peak
https://bugs.launchpad.net/bugs/492841
You received this bug
** Attachment added: corresponding bootchart
http://launchpadlibrarian.net/36502117/acer-tormod-lucid-20091206-9.png
--
throughput goes very low after a first peak
https://bugs.launchpad.net/bugs/492841
You received this bug notification because you are a member of Ubuntu
Bugs, which is
So I guess inode preloading is the high phase, open files is ~zero
throughput, and readahead is moderate.
$ sudo sh -c echo 3 /proc/sys/vm/drop_caches
$ sudo /sbin/ureadahead --debug
/var/lib/ureadahead/pack: created Sun, 06 Dec 2009 16:26:31 + for hdd 8:5
30 inode groups, 2161 files, 4900
This is a CPU and disk graph while I did above test, (400 pixels,
0.1s/update).
** Attachment added: ureadahead.png
http://launchpadlibrarian.net/36508318/ureadahead.png
--
throughput goes very low after a first peak
https://bugs.launchpad.net/bugs/492841
You received this bug notification
** Attachment added: bootchart, rebooted after clean reprofiling
http://launchpadlibrarian.net/36474356/acer-tormod-lucid-20091205-4.png
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/36474357/Dependencies.txt
--
throughput goes very low after a first peak
This is an HDD of course: [1.410710] ata1.00: ATA-8: SAMSUNG
HM160HC, LQ100-10, max UDMA/100
** Attachment added: dmesg
http://launchpadlibrarian.net/36474422/dmesg
--
throughput goes very low after a first peak
https://bugs.launchpad.net/bugs/492841
You received this bug notification
