From: Roger Luethi <rl@hellgate.ch>
To: William Lee Irwin III <wli@holomorphy.com>,
Andrew Morton <akpm@osdl.org>, Rik van Riel <riel@surriel.com>,
torvalds@osdl.org, benh@kernel.crashing.org,
linux-kernel@vger.kernel.org, andrea@suse.de
Subject: Re: Page aging broken in 2.6
Date: Sun, 28 Dec 2003 18:15:12 +0100 [thread overview]
Message-ID: <20031228171512.GA13031@k3.hellgate.ch> (raw)
In-Reply-To: <20031228163528.GK27687@holomorphy.com>
On Sun, 28 Dec 2003 08:35:28 -0800, William Lee Irwin III wrote:
> > the aggregated reference frequency is all that matters. I was merely
> > pointing out how the number of processes referencing a page could affect
> > performance as well. Reference frequency is used as an estimator for
> > the _likelihood_ of a fault in the future, but the potential _impact_
> > of a fault grows with the number of processes that may block on it.
> > It is one possible (though not necessarily the most likely) explanation
> > for the symptoms I see with 2.6.
>
> I guess caution against LFU is uncontroversial.
My bad. What I said is true for both LRU and LFU (they try to predict
the probability of future references), but I wrote "frequency" because
that happened to be on my mind (for unrelated reasons). The point was
basically: risk = probability * damage
> I'm not convinced what vmstat gets out of 2.4 is entirely comparable to
> what it gets out of 2.6. "blocked" and "running" are collected very
Agreed. OTOH those readings are consistent with other observations I
made. It should even be possible to add up the reported idle times and
receive a ballpark figure for the slowdown compared to a system with
more than enough memory.
> differently in 2.6. iowait shouldn't be collected on 2.4 at all.
True. If 2.4 reports idle time during a compile benchmark, though, it
seems plausible to assume it is IO wait. And if 2.6 takes much longer
than 2.4 to complete, it is due to time spend waiting for I/O (minus
some difference in system overhead) -- the work done in user space is
equal, after all.
> This could probably be addressed by backporting 2.6's reporting methods
> to 2.4 so the two kernels use similar reporting mechanisms.
I don't think it's worth it. It wouldn't tell us anything we don't
already know.
> The oscillation in "free" and "buff" is very unusual. What is this
> box doing?
Oops, sorry. That trace is a few months old and I forgot I had used a
hack to have timestamps in vmstat. The large numbers that are alternating
are jiffies, the smaller numbers are the actual readings.
Roger
next prev parent reply other threads:[~2003-12-28 17:16 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-26 7:28 Page aging broken in 2.6 Benjamin Herrenschmidt
2003-12-26 7:40 ` Andrew Morton
2003-12-26 9:21 ` Arjan van de Ven
2003-12-26 9:58 ` Benjamin Herrenschmidt
2003-12-26 19:44 ` Davide Libenzi
2003-12-26 9:33 ` Russell King
2003-12-26 10:07 ` Benjamin Herrenschmidt
2003-12-26 17:59 ` Linus Torvalds
2003-12-26 23:55 ` Benjamin Herrenschmidt
2003-12-27 0:35 ` Linus Torvalds
2003-12-27 0:44 ` Benjamin Herrenschmidt
2003-12-27 0:53 ` Linus Torvalds
2003-12-27 0:59 ` Linus Torvalds
2003-12-27 1:03 ` Benjamin Herrenschmidt
2003-12-27 2:37 ` Andrea Arcangeli
2003-12-27 5:02 ` Benjamin Herrenschmidt
2003-12-27 10:16 ` William Lee Irwin III
2003-12-27 2:47 ` Rik van Riel
2003-12-27 3:00 ` Andrew Morton
2003-12-27 3:31 ` Rik van Riel
2003-12-27 3:54 ` Linus Torvalds
2003-12-27 16:34 ` Martin J. Bligh
2003-12-27 23:07 ` Roger Luethi
2003-12-27 23:55 ` William Lee Irwin III
2003-12-28 11:23 ` Roger Luethi
2003-12-28 16:35 ` William Lee Irwin III
2003-12-28 17:15 ` Roger Luethi [this message]
2003-12-28 0:04 ` Andrew Morton
2003-12-28 11:58 ` Roger Luethi
2003-12-27 1:41 ` Andrea Arcangeli
-- strict thread matches above, loose matches on Subject: below --
2003-12-26 10:45 Manfred Spraul
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=20031228171512.GA13031@k3.hellgate.ch \
--to=rl@hellgate.ch \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@surriel.com \
--cc=torvalds@osdl.org \
--cc=wli@holomorphy.com \
/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