Jens Axboe <[email protected]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |