lkml.org 
[lkml]   [2002]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:1.637 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site