Linus Torvalds writes:
>
> On Sun, 13 May 2001, Richard Gooch wrote:
> >
> > Think about it:-) You need to generate prefetch accesses in ascending
> > device bnum order.
>
> I seriously doubt it is worth it.
>
> Th ekernel will do the ordering for you anyway: that's what the
> elevator is, and that's why you have a "prefetch" system call (to
> avoid the synchronization that kills the elevator). And you'll end
> up wanting to pre-fetch on virtual addresses, which implies that you
> have to open the files: I doubt you want to have tons of files open
> and try to get a "global" order.
OK, provided the prefetch will queue up a large number of requests
before starting the I/O. If there was a way of controlling when the
I/O actually starts (say by having a START flag), that would be ideal,
I think.
> But sure, you can use bmap if you want. It would be interesting to
> hear whether it makes much of a difference..
I doubt bmap() would make any difference if there is a way of
controlling when the I/O starts.
However, this still doesn't address the issue of indirect blocks. If
the indirect block has a higher bnum than the data blocks it points
to, you've got a costly seek. This is why I'm still attracted to the
idea of doing this at the block device layer. It's easy to capture
*all* accesses and then warm the buffer cache.
So, why can't the page cache check if a block is in the buffer cache?
> > Sure, this would work too. I'm a bit worried about the increased
> > amount of traffic this will generate.
>
> No increased traffic. "path" is a pointer (to a dentry), ie 32
> bits. "ino" is at least 128 bits on some filesystems. You make for _less_
> data to save.
>
> > So on every page fault or read(2) call, we have to generate the full
> > path from the dentry? Isn't that going to add a fair bit of overhead?
>
> You just save the dentry pointer. You do the path _later_, when
> somebody reads it away from the /proc file.
That opens up a nasty race: if the dentry is released before the
pointer is harvested, you get a bogus pointer.
> > I don't see the advantage of the prefetch(2) system call. It seems to
> > me I can get the same effect by just making read(2) calls in another
> > task. Of course, I'd need to use bmap() to generate the sort key, but
> > I don't see why that's a bad thing.
>
> Try it. You won't be able to. "read()" is an inherently
> synchronizing operation, and you cannot get _any_ overlap with
> multiple reads, except for the pre-fetching that the kernel will do
> for you anyway.
How's that? It won't matter if read(2) synchronises, because I'll be
issuing the requests in device bnum order.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/
This archive was generated by hypermail 2b29 : Tue May 15 2001 - 21:00:34 EST