From: Wu Fengguang <wfg@mail.ustc.edu.cn>
To: Valdis.Kletnieks@vt.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: Adaptive Readahead V14 - statistics question...
Date: Tue, 30 May 2006 08:37:57 +0800 [thread overview]
Message-ID: <348949470.27872@ustc.edu.cn> (raw)
Message-ID: <20060530003757.GA5164@mail.ustc.edu.cn> (raw)
In-Reply-To: <200605291944.k4TJixBW011192@turing-police.cc.vt.edu>
On Mon, May 29, 2006 at 03:44:59PM -0400, Valdis.Kletnieks@vt.edu wrote:
> Running 2.6.17-rc4-mm3 + V14. I see this in /debug/readahead/events:
>
> [table summary] total initial state context contexta backward onthrash onseek none
> random_rate 8% 0% 4% 46% 9% 44% 0% 38% 18%
> ra_hit_rate 89% 97% 90% 40% 83% 76% 0% 49% 0%
> la_hit_rate 62% 99% 88% 29% 84% 9500% 0% 200% 3700%
> var_ra_size 703 4 8064 39 5780 3 0 59 3010
> avg_ra_size 6 2 67 6 33 2 0 4 36
> avg_la_size 37 1 96 4 45 0 0 0 0
>
> Are the 9500%, 200%, and 3700% numbers in la_hit_rate related to reality
> in any way, or is something b0rken?
It's ok. They are computed from the following lines:
> lookahead 1972 153 671 1050 98 0 0 0 0
> lookahead_hit 1241 152 596 312 84 95 0 2 37
Here 'lookahead_hit' can somehow be greater than 'lookahead', which means
'cache hit' happened. i.e. the new readahead request overlapped with
some previous ones, and the 'lookahead_hit' is counted into the wrong
place. The 'cache hit' can also make the 'readahead_hit' larger or smaller.
This kind of mistakes can happen randomly because the accounting
mechanism is simple and supposed to work in normal. However there's no
guarantee of exact accurate - or the overhead will be unacceptable.
> And is there any documentation on what these mean, so you can tell if it's
This code snip helps a bit understanding:
/* Read-ahead events to be accounted. */
enum ra_event {
RA_EVENT_CACHE_MISS, /* read cache misses */
RA_EVENT_RANDOM_READ, /* random reads */
RA_EVENT_IO_CONGESTION, /* i/o congestion */
RA_EVENT_IO_CACHE_HIT, /* canceled i/o due to cache hit */
RA_EVENT_IO_BLOCK, /* wait for i/o completion */
RA_EVENT_READAHEAD, /* read-ahead issued */
RA_EVENT_READAHEAD_HIT, /* read-ahead page hit */
RA_EVENT_LOOKAHEAD, /* look-ahead issued */
RA_EVENT_LOOKAHEAD_HIT, /* look-ahead mark hit */
RA_EVENT_LOOKAHEAD_NOACTION, /* look-ahead mark ignored */
RA_EVENT_READAHEAD_MMAP, /* read-ahead for mmap access */
RA_EVENT_READAHEAD_EOF, /* read-ahead reaches EOF */
RA_EVENT_READAHEAD_SHRINK, /* ra_size falls under previous la_size */
RA_EVENT_READAHEAD_THRASHING, /* read-ahead thrashing happened */
RA_EVENT_READAHEAD_MUTILATE, /* read-ahead mutilated by imbalanced aging */
RA_EVENT_READAHEAD_RESCUE, /* read-ahead rescued */
RA_EVENT_READAHEAD_CUBE,
RA_EVENT_COUNT
};
> doing anything useful? (One thing I've noticed is that xmms, rather than gobble
> up 100K of data off disk every 10 seconds or so, snarfs a big 2M chunk every
> 3-4 minutes, often sucking in an entire song at (nearly) one shot...)
Hehe, it's resulted from the enlarged default max readahead size(128K => 1M).
Too much aggressive? I'm interesting to know the recommended size for
desktops, thanks. For now you can adjust it through the 'blockdev
--setra /dev/hda' command.
Wu
--
> (Complete contents of readahead/events follows, in case it helps diagnose...)
>
> [table requests] total initial state context contexta backward onthrash onseek none
> cache_miss 3934 543 93 2013 39 1199 0 47 417
> random_read 1772 59 49 1059 11 575 0 19 327
> io_congestion 4 0 4 0 0 0 0 0 0
> io_cache_hit 1082 1 63 855 14 144 0 5 0
> io_block 26320 18973 3519 2225 265 1288 0 50 1371
> readahead 18601 15540 1008 1203 110 710 0 30 1483
> lookahead 1972 153 671 1050 98 0 0 0 0
> lookahead_hit 1241 152 596 312 84 95 0 2 37
> lookahead_ignore 0 0 0 0 0 0 0 0 0
> readahead_mmap 0 0 0 0 0 0 0 0 0
> readahead_eof 14951 14348 569 19 15 0 0 0 0
> readahead_shrink 0 0 0 0 0 0 0 0 70
> readahead_thrash 0 0 0 0 0 0 0 0 0
> readahead_mutilt 0 0 0 0 0 0 0 0 0
> readahead_rescue 0 0 0 0 0 0 0 0 138
>
> [table pages] total initial state context contexta backward onthrash onseek none
> cache_miss 6541 2472 754 2026 43 1199 0 47 1194
> random_read 1784 62 51 1065 12 575 0 19 337
> io_congestion 396 0 396 0 0 0 0 0 0
> io_cache_hit 10185 2 571 7930 1383 293 0 6 0
> readahead 111015 30757 67949 6864 3642 1681 0 122 53677
> readahead_hit 98812 30052 61602 2762 3041 1294 0 61 277
> lookahead 72607 185 64222 3734 4466 0 0 0 0
> lookahead_hit 68640 184 59207 4475 4774 0 0 0 0
> lookahead_ignore 0 0 0 0 0 0 0 0 0
> readahead_mmap 0 0 0 0 0 0 0 0 0
> readahead_eof 39959 25045 14102 64 748 0 0 0 0
> readahead_shrink 0 0 0 0 0 0 0 0 1076
> readahead_thrash 0 0 0 0 0 0 0 0 0
> readahead_mutilt 0 0 0 0 0 0 0 0 0
> readahead_rescue 0 0 0 0 0 0 0 0 9538
>
> [table summary] total initial state context contexta backward onthrash onseek none
> random_rate 8% 0% 4% 46% 9% 44% 0% 38% 18%
> ra_hit_rate 89% 97% 90% 40% 83% 76% 0% 49% 0%
> la_hit_rate 62% 99% 88% 29% 84% 9500% 0% 200% 3700%
> var_ra_size 703 4 8064 39 5780 3 0 59 3010
> avg_ra_size 6 2 67 6 33 2 0 4 36
> avg_la_size 37 1 96 4 45 0 0 0 0
>
next prev parent reply other threads:[~2006-05-30 0:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-29 19:44 Valdis.Kletnieks
[not found] ` <20060530003757.GA5164@mail.ustc.edu.cn>
2006-05-30 0:37 ` Wu Fengguang [this message]
2006-05-30 3:36 Voluspa
[not found] ` <20060530064026.GA4950@mail.ustc.edu.cn>
2006-05-30 6:40 ` Wu Fengguang
2006-05-30 16:49 ` Valdis.Kletnieks
2006-05-31 21:06 ` Diego Calleja
2006-05-31 21:50 ` Voluspa
[not found] ` <20060601055143.GA5216@mail.ustc.edu.cn>
2006-06-01 5:51 ` Fengguang Wu
2006-06-01 6:35 ` Voluspa
2006-06-08 8:04 ` Voluspa
[not found] ` <448493E9.9030203@samwel.tk>
[not found] ` <20060606033436.GB6071@mail.ustc.edu.cn>
2006-06-06 3:34 ` Wu Fengguang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=348949470.27872@ustc.edu.cn \
--to=wfg@mail.ustc.edu.cn \
--cc=Valdis.Kletnieks@vt.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome