Ingo Molnar wrote:
* Nick Piggin <[email protected]> wrote:
i'm wondering about swap-prefetch:
Being able to config all these core heuristics changes is really not
that much of a positive. The fact that we might _need_ to config
something out, and double the configuration range isn't too pleasing.
Well, to the desktop user this is a speculative performance feature that
he is willing to potentially waste CPU and IO capacity, in expectation
of better performance.
On the conceptual level it is _precisely the same thing as regular file
readahead_. (with the difference that to me swapahead seems to be quite
a bit more intelligent than our current file readahead logic.)
This feature has no API or ABI impact at all, it's a pure performance
feature. (besides the trivial sysctl to turn it runtime on/off).
Here were some of my concerns, and where our discussion got up to.
[...snip...]
i see no real problem here. We've had heuristics for a _long_ time in
various areas of the code. Sometimes they work, sometimes they suck.
the flow of this is really easy: distro looking for a feature edge turns
it on and announces it, if the feature does not work out for users then
user turns it off and complains to distro, if enough users complain then
distro turns it off for next release, upstream forgets about this
performance feature and eventually removes it once someone notices that
it wouldnt even compile in the past 2 main releases. I see no problem
here, we did that in the past too with performance features. The
networking stack has literally dozens of such small tunable things which
get experimented with, and whose defaults do get tuned carefully. Some
of the knobs help bandwidth, some help latency.
I haven't looked at this code since it first came out and didn't impress
me, but I think it would be good to get the current version in. However,
when you say "user turns it off" I hope you mean "in /proc/sys with a
switch or knob" and not by expecting people to recompile and install a
kernel. Then it might take a little memory but wouldn't do something
undesirable.
Note: I had no bad effect from the code, it just didn't feel faster. On
a low memory machine it might help. Of course I have wanted to have a
hard limit on memory used for i/o buffers, just to avoid swapping
programs to make room for i/o, so to some extent I feel as if this is a
fix for a problem we shouldn't have.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
