Re: swap-prefetch: 2.6.22 -mm merge plans

From: Bill Davidsen
Date: Mon May 07 2007 - 10:18:48 EST


Ingo Molnar wrote:
* Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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 <davidsen@xxxxxxx>
"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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/