lkml.org 
[lkml]   [2005]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [git patches] IDE update
    Jens Axboe wrote:

    >On Fri, Jul 08 2005, Andrew Morton wrote:
    >
    >
    >>Jens Axboe <axboe@suse.de> wrote:
    >>
    >>
    >>>Some more investigation - it appears to be broken read-ahead, actually.
    >>> hdparm does repeated read(), lseek() loops which causes the read-ahead
    >>> logic to mark the file as being in cache (since it reads the same chunk
    >>> every time). Killing the INCACHE check (attached) makes it work fine for
    >>> me, Grant can you test if it "fixes" it for you as well?
    >>>
    >>> No ideas how to fix the read-ahead logic right now, I pondered some
    >>> depedency on sequential but I don't see how it can work correctly for
    >>> other cases. Perhaps handle_ra_miss() just isn't being called
    >>> appropriately everywhere?
    >>>
    >>> --- mm/readahead.c~ 2005-07-08 11:16:14.000000000 +0200
    >>> +++ mm/readahead.c 2005-07-08 11:17:49.000000000 +0200
    >>> @@ -351,7 +351,9 @@
    >>> ra->cache_hit += nr_to_read;
    >>> if (ra->cache_hit >= VM_MAX_CACHE_HIT) {
    >>> ra_off(ra);
    >>> +#if 0
    >>> ra->flags |= RA_FLAG_INCACHE;
    >>> +#endif
    >>> return 0;
    >>> }
    >>> } else {
    >>>
    >>>
    >>Interesting. We should be turning that back off in handle_ra_miss() as
    >>soon as hdparm seeks away. I'd be suspecting that we're not correctly
    >>undoing the resutls of ra_off() within handle_ra_miss(), except you didn't
    >>comment that bit out.
    >>
    >>Or the readahead code is working as intended, and hdparm is doing something
    >>really weird which trips it up.
    >>
    >>hdparm should also be misbehaving when run against a regular file, but it
    >>looks like hdparm would need some alterations to test that.
    >>
    >>
    >
    >Just use the test app I posted, it shows the problem just fine. If I use
    >a regular file, behaviour is identical as expected (ie equally broken
    >:-).
    >
    >bart:/data1 # ./read_disk ./test 1
    >Mem Throughput: 101 MiB/sec
    >Mem Throughput: 103 MiB/sec
    >Disk Throughput: 22 MiB/sec
    >
    >bart:/data1 # ./read_disk ./test
    >Disk Throughput: 29 MiB/sec
    >
    >

    I don't see how this is broken. The INCACHE flag should be cleared on
    the first miss. We will start up I/O slightly slower in this case since
    it is not 1st IO, but within about 5 or 6 reads we should be back to
    normal max_readahead behavior. This is what I see on my old laptop.


    patches:/home/slpratt # ./readdisk /dev/hda
    Disk Throughput: 16 MiB/sec
    patches:/home/slpratt # ./readdisk /dev/hda 1
    Mem Throughput: 145 MiB/sec
    Mem Throughput: 153 MiB/sec
    Disk Throughput: 16 MiB/sec


    Can you post iostat -x output from your runs. Are we doing the right
    sized IO?

    Steve



    -
    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-07-09 00:33    [W:9.628 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site