linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

      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