From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
arjanv@redhat.com, Rik van Riel <riel@nl.linux.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Thinko in kswapd?
Date: Thu, 22 Mar 2001 18:18:08 +0000 [thread overview]
Message-ID: <20010322181808.B7756@redhat.com> (raw)
In-Reply-To: <20010322145810.A7296@redhat.com> <Pine.LNX.4.31.0103220931330.18728-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.31.0103220931330.18728-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Thu, Mar 22, 2001 at 09:36:48AM -0800
Hi,
On Thu, Mar 22, 2001 at 09:36:48AM -0800, Linus Torvalds wrote:
> On Thu, 22 Mar 2001, Stephen C. Tweedie wrote:
> >
> > There is what appears to be a simple thinko in kswapd. We really
> > ought to keep kswapd running as long as there is either a free space
> > or an inactive page shortfall; but right now we only keep going if
> > _both_ are short.
>
> Hmm.. The comment definitely says "or", so changing it to "and" in the
> sources makes the comment be non-sensical.
Indeed.
> I suspect that the comment and the code were true at some point. The
> behaviour of "do_try_to_free_pages()" has changed, though, and I suspect
> your suggested change makes more sense now (it certainly seems to be
> logical to have the reverse condition for sleeping and for when to call
> "do_try_to_free_pages()").
> The only way to know is to test the behaviour. My only real worry is that
> kswapd might end up eating too much CPU time and make the system feel bad,
> but on the other hand the same can certainly be true from _not_ doing this
Yes, it's more the inconsistency between the tests than the tests that
prompted me to try it, and the scale of the interactive performance
improvement was quite a surprise.
On the other hand, Alan is now reporting that on one of his workloads
it does cause erratic behaviour for interactive loads. So this is
definitely not a cure-all.
We already do have some problems with excessive swap time being
consumed under some loads: I can reproduce stalls of several seconds
on a PAE box with simple "dd > /dev/sd*". That's something I need to
follow up further once we've found the source of some SMP data
corruption we're still seeing on big boxes (I'll be sending patches
for a shm race shortly that we found while chasing this.)
I suspect we'll need to instrument the activity of the various lrus in
the VM more accurately before we'll ever understand _why_ the VM works
well or badly in any given situation.
Cheers,
Stephen
WARNING: multiple messages have this Message-ID (diff)
From: "Stephen C. Tweedie" <sct@redhat.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
arjanv@redhat.com,
Rik van Riel <riel@nl.linux.org>Alan Cox
<alan@lxorguk.ukuu.org.uk>
Subject: Re: Thinko in kswapd?
Date: Thu, 22 Mar 2001 18:18:08 +0000 [thread overview]
Message-ID: <20010322181808.B7756@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.31.0103220931330.18728-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Thu, Mar 22, 2001 at 09:36:48AM -0800
Hi,
On Thu, Mar 22, 2001 at 09:36:48AM -0800, Linus Torvalds wrote:
> On Thu, 22 Mar 2001, Stephen C. Tweedie wrote:
> >
> > There is what appears to be a simple thinko in kswapd. We really
> > ought to keep kswapd running as long as there is either a free space
> > or an inactive page shortfall; but right now we only keep going if
> > _both_ are short.
>
> Hmm.. The comment definitely says "or", so changing it to "and" in the
> sources makes the comment be non-sensical.
Indeed.
> I suspect that the comment and the code were true at some point. The
> behaviour of "do_try_to_free_pages()" has changed, though, and I suspect
> your suggested change makes more sense now (it certainly seems to be
> logical to have the reverse condition for sleeping and for when to call
> "do_try_to_free_pages()").
> The only way to know is to test the behaviour. My only real worry is that
> kswapd might end up eating too much CPU time and make the system feel bad,
> but on the other hand the same can certainly be true from _not_ doing this
Yes, it's more the inconsistency between the tests than the tests that
prompted me to try it, and the scale of the interactive performance
improvement was quite a surprise.
On the other hand, Alan is now reporting that on one of his workloads
it does cause erratic behaviour for interactive loads. So this is
definitely not a cure-all.
We already do have some problems with excessive swap time being
consumed under some loads: I can reproduce stalls of several seconds
on a PAE box with simple "dd > /dev/sd*". That's something I need to
follow up further once we've found the source of some SMP data
corruption we're still seeing on big boxes (I'll be sending patches
for a shm race shortly that we found while chasing this.)
I suspect we'll need to instrument the activity of the various lrus in
the VM more accurately before we'll ever understand _why_ the VM works
well or badly in any given situation.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-03-22 18:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-22 14:58 Thinko in kswapd? Stephen C. Tweedie
2001-03-22 17:36 ` Linus Torvalds
2001-03-22 17:36 ` Linus Torvalds
2001-03-22 18:18 ` Stephen C. Tweedie [this message]
2001-03-22 18:18 ` Stephen C. Tweedie
2001-03-22 17:53 ` Mike Galbraith
2001-03-22 17:53 ` Mike Galbraith
2001-03-22 18:09 ` Alan Cox
2001-03-22 18:09 ` Alan Cox
2001-03-22 18:22 ` Mike Galbraith
2001-03-22 18:22 ` Mike Galbraith
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=20010322181808.B7756@redhat.com \
--to=sct@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjanv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@nl.linux.org \
--cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.