From: Linus Torvalds <torvalds@transmeta.com>
To: Roger Larsson <roger.larsson@norran.net>
Cc: zlatko@iskon.hr,
"linux-kernel@vger.rutgers.edu" <linux-kernel@vger.rutgers.edu>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [linux-audio-dev] Re: [PATCH really] latency improvements, one reschedule moved
Date: Fri, 7 Jul 2000 18:58:41 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.10.10007071846510.3444-100000@penguin.transmeta.com> (raw)
In-Reply-To: <396653EC.5D146D55@norran.net>
On Sat, 8 Jul 2000, Roger Larsson wrote:
>
> I examined the patches again and the fact that it runs
> do_try_to_free_pages
> periodically may improve performance due to its page cleaning effect -
> all pages won't be dirty at the same time...
One potential problem with this, though, is that it keeps shrinking the
dcache etc: even though various parts of the system refuse to touch pages
once the machine has "enough" memory, the periodic wake-up will cause
those caches that don't have the "I don't need to do this" logic to
potentially be starved.
The keep_kswapd_awake() logic protects from the worst case (it won't go on
forever), but I wonder if it might still not cause bad behaviour when one
zone is getting balanced and the other zones shouldn't be touched, but the
continual trickle will cause the dcache etc stuff to be free'd with very
little good reason.
The "one zone gets rebalanced" is normal behaviour, so this is why I worry
about the dcache.
> But it has a downside too - it will destroy the LRU order of pages...
> PG_referenced loses some of its meaning...
That part doesn't bother me in the least - it can be seen as a simple
aging of the referenced bit. Especially if we're going to re-introduce the
multi-bit page "age" code, aging the reference bits actually only improves
stuff.
The fact that shrink_mmap() gets called regularly also makes bdflush
potentially less important, because shrink_mmap() actually does a better
job of flushing dirty data anyway these days, and in many ways it makes
sense to have this kind of background LRU list activity.
Linus
--
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/
prev parent reply other threads:[~2000-07-08 1:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-01 2:06 [PATCH] " Roger Larsson
2000-07-05 0:50 ` Roger Larsson
2000-07-05 19:29 ` [PATCH really] " Roger Larsson
2000-07-06 19:48 ` Zlatko Calusic
2000-07-07 22:04 ` [linux-audio-dev] " Roger Larsson
2000-07-08 1:58 ` Linus Torvalds [this message]
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=Pine.LNX.4.10.10007071846510.3444-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=roger.larsson@norran.net \
--cc=zlatko@iskon.hr \
/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