From: Al Boldi <a1426z@gawab.com>
To: Chris Snook <csnook@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: swap-prefetch: A smart way to make good use of idle resources (was: updatedb)
Date: Sat, 28 Jul 2007 07:18:31 +0300 [thread overview]
Message-ID: <200707280718.31272.a1426z@gawab.com> (raw)
In-Reply-To: <46AAA25E.7040301@redhat.com>
Chris Snook wrote:
> Al Boldi wrote:
> > IMHO, what everybody agrees on, is that swap-prefetch has a positive
> > effect in some cases, and nobody can prove an adverse effect (excluding
> > power consumption). The reason for this positive effect is also crystal
> > clear: It prefetches from swap on idle into free memory, ie: it doesn't
> > force anybody out, and they are the first to be dropped without further
> > swap-out, which sounds really smart.
> >
> > Conclusion: Either prove swap-prefetch is broken, or get this merged
> > quick.
>
> If you can't prove why it helps and doesn't hurt, then it's a hack, by
> definition.
Ok, slow down: swap-prefetch isn't a hack. It's a kernel-thread that adds
swap-prefetch functionality to the kernel.
> With swap prefetch, we're only optimizing the case when the box isn't
> loaded and there's RAM free, but we're not optimizing the case when the
> box is heavily loaded and we need for RAM to be free.
Exactly, swap-prefetch is very specific, and that's why it's so successful:
It does one thing, and it does that very well.
> I'm inclined to view swap prefetch as a successful scientific experiment,
> and use that data to inform a more reasoned engineering effort. If we can
> design something intelligent which happens to behave more or less like
> swap prefetch does under the circumstances where swap prefetch helps, and
> does something else smart under the circumstances where swap prefetch
> makes no discernable difference, it'll be a much bigger improvement.
Well, a swapless OS would really be the ultimate, but that's another thread
entirely (see thread: '[RFC] VM: I have a dream...')
Don't mistake swap-prefetch as trying to additionally fix swap-in slowdown,
and if it did, then that would be a hack, but it doesn't.
Instead, understand that swap-prefetch is viable even if all swapper issues
have been solved, because swapping implies pages being swapped in when
needed, and swap-prefetch smartly uses idle time to do so.
> Because we cannot prove why the existing patch helps, we cannot say what
> impact it will have when things like virtualization and solid state drives
> radically change the coefficients of the equation we have not solved.
> Providing a sysctl to turn off a misbehaving feature is a poor substitute
> for doing it right the first time, and leaving it off by default will
> ensure that it only gets used by the handful of people who know enough to
> rebuild with the patch anyway.
But we do know why it helps: a proc eats memory, then page-cache, then swaps
others out, and then dies to free its memory, and now swap-prefetch comes in
if the system is idle. Sounds really smart.
While many people may definitely benefit, others may just want to turn it
off. No harm done.
Thanks!
--
Al
--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2007-07-28 4:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200707272243.02336.a1426z@gawab.com>
2007-07-28 1:56 ` Chris Snook
2007-07-28 4:17 ` How can we make page replacement smarter (was: swap-prefetch) Al Boldi
2007-07-28 7:27 ` Chris Snook
2007-07-28 11:11 ` Al Boldi
2007-07-29 4:07 ` Rik van Riel
2007-07-29 6:40 ` Erblichs
2007-07-29 1:46 ` How can we make page replacement smarter Rik van Riel
2007-07-29 13:09 ` Alan Cox
2007-07-29 15:01 ` Rik van Riel
2007-07-29 14:55 ` Al Boldi
2007-07-28 4:18 ` Al Boldi [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=200707280718.31272.a1426z@gawab.com \
--to=a1426z@gawab.com \
--cc=csnook@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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