26 Jan
2009
26 Jan
'09
09:58
Am Montag 26 Januar 2009 schrieb Michael Meeks: Hi Michael, > * how does preload differ from sreadahead ? sreadahead: - does open, seek and readahead - reads parts sync - does 4 threads with low I/O priority detached - uses boot order (by means of kernel patch for ext3) - needs pregenerated lists from boots not using sreadahead - there is only one sreadhead started very early preload: - does stat, open and fadvise - reads whole file async - does one process with high I/O priority blocking - uses predefined list that can be regenerated without changing boot - there are several preload phases All in all: they differ more than they have in common. preload is pretty close to prefetch though, but doesn't require kernel patches. I guess sreadahead is helping with certain SSDs only, there it's necessary to get the kernel to create throughput as quickly as possible and seeks don't hurt. That's different to my laptop hdd. According to the sources, sreadahead doesn't need the kernel patch, it only optimzes the order. But still, calling sreadahead early doesn't improve my boot time. And it's much harder to deploy too, more suited to show cases ;) > * do you take the moblin route: > + of running preload asynchronously at the lowest > I/O priority > + of growing /sys/proc/sda/queue/nr_requests to > 1024+ [ supposedly so the fairness code works ;-) Doesn't change _anything_ - it defaults to 128 and the queue never gets that long. At least neither with sreadahead nor with preload. And yes, I tested (of course I used the correct the name - around /sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/block/sda/queue/nr_requests, there is no /sys/proc). But nice anecdote. I also tested different elevators. All others (ant11y, noop, deadline) are slower than cfq with preload. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org