lkml.org 
[lkml]   [2001]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Getting FS access events


    On Sun, 13 May 2001, Richard Gooch wrote:
    >
    > 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.

    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/

    \
     
     \ /
      Last update: 2005-03-22 12:53    [W:0.024 / U:122.976 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site