Ehh. The "start" flag is when you actually start reading, or when you've
prefetched so much that the queue has filled up. That's the behaviour
you'd get naturally, and it's the behaviour you want.
> So, why can't the page cache check if a block is in the buffer cache?
Because it would make the damn thing slower.
The whole point of the page cache is to be FAST FAST FAST. The reason we
_have_ a page cache is that the buffer cache is slow and inefficient, and
it will always remain so.
We want to get _away_ from the buffer cache, not add support for a legacy
cache into the new and more efficient one.
And remember: when raw devices are in the page cache, you simply WILL NOT
HAVE a buffer cache at all.
Just stop this line of thought. It's not going anywhere.
> That opens up a nasty race: if the dentry is released before the
> pointer is harvested, you get a bogus pointer.
..which is why you increment the dentry count when you profile it, and
decrement it when you have output the path...
> > 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.
Ehh.. You don't seem to know how disks work.
By the time you follow up with the next "read", the platter will probably
have rotated past the point you want to read. You need to have multiple
outstanding requests (or _biiig_ requests) to get close to platter speed.
[ Aside: with most IDE stuff doing extensive track buffering, you won't
see this as much. It depends on the disk, the cache size, and the
buffering characteristics. ]
Linus
-
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/