mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Indan Zupancic" <indan@nul.nu>
To: "grundig" <grundig@teleline.es>
Cc: "Arjan van de Ven" <arjan@infradead.org>,
	"Al Boldi" <a1426z@gawab.com>,
	linux-kernel@vger.kernel.org
Subject: Re: swap-prefetch:  A smart way to make good use of idle resources  (was: updatedb)
Date: Sat, 28 Jul 2007 02:03:19 +0200 (CEST)	[thread overview]
Message-ID: <50998.81.207.0.53.1185580999.squirrel@secure.samage.net> (raw)
In-Reply-To: <20070728013251.7c110223.grundig@teleline.es>

On Sat, July 28, 2007 01:34, grundig wrote:
> El Fri, 27 Jul 2007 15:06:14 -0700, Arjan van de Ven <arjan@infradead.org> escribi�:
>
>> how do you know there will be other activity? You start the IO and that
>> basically blacks out the disk for 5 to 10 ms. If the "real" IO gets
>> submitted in that time you add latency. You cannot predict that IO
>> happening or not happening.
>
> If there hasn't be much IO for some time, it looks quite reasonable to expect
> that there won't be more in the near future.

Good argument.

> As most of heuristics can fail, but
> then this is a feature mostly for desktops, not servers.

Bad argument. It doesn't matter for who the feature is intended, it matter
what it does and if it does it well or not. In this case, prefetching swap without
disturbing anything else.

> There's an old saying that says something like "an open source project starts
> dying when new people can't participate in the project no matter how hard
> they try". It's hard to understand why there's so many people opposing to
> this when other more controversial features are merged much faster, (like, fe.
> the UIO driver framework).

Could people please stop this emotional crap non-argumentation? At best it reduces
the chance of swap-prefetch to be merged.

Perhaps one of the reasons is that this is core kernel code. And that it isn't a new
feature, but a performance improvement with doubtful trade-offs. The problem
statement isn't clear either. It seems like a natural enhancement, but is that enough
reason to merge it? Maybe, maybe not. But if slow swap-in is the problem, shouldn't
that be fixed instead of bypassed?

Yes, there are people that say that it works for them, but of those a lot claim
updatedb damage is fixed by it too, while that can't be true. And how many of those
people did test swap prefetch stand-alone? The ck kernel has other mm patches too,
perhaps those are the real goodies...

And there don't seem to be many people opposing swap prefetch either. A bunch seem
in favour of it, and others seem unconvinced.

Me, I don't know if it should be merged or not, it solves one very specific workload, and
nothing else (swap is used, and memory becomes free which won't be used in the near
future). All in all it seems good, but doubtful, and when in doubt, don't merge.

Greetings,

Indan



  parent reply	other threads:[~2007-07-28  0:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-27 19:43 Al Boldi
2007-07-27 20:34 ` Arjan van de Ven
2007-07-27 21:51   ` Indan Zupancic
2007-07-27 22:06     ` Arjan van de Ven
2007-07-27 22:20       ` Indan Zupancic
2007-07-27 23:34       ` grundig
2007-07-27 23:59         ` Arjan van de Ven
2007-07-28  0:03         ` Indan Zupancic [this message]
2007-07-28 15:42           ` grundig
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  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   ` swap-prefetch: A smart way to make good use of idle resources (was: updatedb) Al Boldi

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=50998.81.207.0.53.1185580999.squirrel@secure.samage.net \
    --to=indan@nul.nu \
    --cc=a1426z@gawab.com \
    --cc=arjan@infradead.org \
    --cc=grundig@teleline.es \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®