Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: linux-2.4.10-pre5 | Date | Tue, 11 Sep 2001 18:07:03 +0200 |
| |
On September 11, 2001 05:48 pm, Linus Torvalds wrote: > On Tue, 11 Sep 2001, Daniel Phillips wrote: > > > > But see my post in this thread where I created a simple test to show that, > > even when we pre-read *all* the inodes in a directory, there is no great > > performance win. > > Note that I suspect that because the inode tree _is_ fairly dense, you > don't actually need to do much read-ahead in most cases. Simply because > you automatically do read-ahead _always_: when somebody reads a 128-byte > inode, you (whether you like it or not) always "read-ahead" the 31 inodes > around it on a 4kB filesystem. > > So we _already_ do read-ahead by a "factor of 31". Whether we can improve > that or not by increasing it to 63 inodes, who knows? > > I actually think that the "start read-ahead for inode blocks when you do > readdir" might be a bigger win, because that would be a _new_ kind of > read-ahead that we haven't done before, and might improve performance for > things like "ls -l" in the cold-cache situation..
But wait, if our theories are correct then the disk is doing physical readahead anyway, and its a nice scsi disk with lots of cache, so *why does it take so long to read the metadata*? It's about 11,000 files, that's 1.3Meg of inodes and just a couple hundred K of directories.
There is clearly something nonoptimal about the hardware readahead and/or caching.
> (Although again, because the inode is relatively small to the IO cache > size, it's probably fairly _hard_ to get a fully cold-cache inode case. So > I'm not sure even that kind of read-ahead would actually make any > difference at all).
-- Daniel - 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/
|  |