Messages in this thread | | | Date | Mon, 07 Oct 2002 11:31:42 -0700 | From | Andrew Morton <> | Subject | Re: The reason to call it 3.0 is the desktop (was Re: [OT] 2.6 not 3.0 - (NUMA)) |
| |
Daniel Phillips wrote: > > On Sunday 06 October 2002 17:19, Martin J. Bligh wrote: > > > Then there's the issue of application startup. There's not enough > > > read ahead. This is especially sad, as the order of page faults is > > > at least partially predictable. > > > > Is the problem really, fundamentally a lack of readahead in the > > kernel? Or is it that your application is huge bloated pig? > > Readahead isn't the only problem, but it is a huge problem. The current > readahead model is per-inode, which is very little help with lots of small > files, especially if they are fragmented or out of order. There are various > ways to fix this; they are all difficult[1]. Fortunately, we can call this > "tuning work" so it can be done during the stable series. > > [1] We could teach each filesystem how to read ahead across directories, or > we could teach the vfs how to do physical readahead. Choose your poison.
Devices do physical readahead, and it works nicely.
Go into ext2_new_inode, replace the call to find_group_dir with find_group_other. Then untar a kernel tree, unmount the fs, remount it and see how long it takes to do a
`find . -type f xargs cat > /dev/null'
on that tree. If your disk is like my disk, you will achieve full disk bandwidth. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |