Paul M Foster wrote:
>
> I'm inclined to agree with Linus overall about the AA VM. Not because I
> know anything, but 1) rewrites based on past experience _which actually
> work_ are generally better than patching old code, 2) I've heard that
> the AA VM is simpler in design, which is always a plus, and 3) I think
> Linus is pretty sharp; if he likes it enough to drop it in, it's
> probably okay. Not to detract from Alan Cox, who is also deeply gifted.
> Alan tends to be more conservative.
Rik's VM work actually has a lot going for it. The big surprise when I
ran those tests was how well rik's VM handled extremely high load and
extremely low memory pressure. The way I understand it is Rik's VM
tries to be much smarter about what to swap out, so that it doesn't have
to turn back around and swap a bunch of stuff back in, i.e. thrash
swap. AA's "new" VM design (which apparently draws considerably from
the 2.2 VM for basic idea) *is* much simpler, but that also means it has
less heuristics built in about how to manage the memory. The difference
between the two is easily seen in both the "low memory" and "high
load/low memory" test run where Rik's VM ran circles around the AA VM
design, because it had to thrash swap much less.
I really think Rik's design is going the right direction and personally
I think it's very much worth keeping in a mainline kernel. Or at least
I can hope that the AA VM will take some ideas from Rik's work and
integrate if possible.
The tradeoff with both VM concepts is that, to handle the "big" cases
like an 8-way box with 16GB of RAM, they have to do more work up front
in all cases. So the perceived speediness of the system is reduced,
even though the actual speediness is really increased. Which is why a
lot of people are trying to get the "preemptible kernel" patches
integrated into mainline kernel code. The "preemptible" code allows the
kernel to interrupt itself, while running in kernel mode, so that if
someone moves the mouse for example, the kernel will interrupt what it's
doing, even when it's kernel activity in most cases, to respond to that
activity, decreasing latency and increasing the overall "feel" of
snappiness. Of course, again, the tradeoff then is higher overhead from
more context switching, so overall *actual* speed will be reduced again.
The trouble with the 2.4 series has mainly been finding that balance
between overhead and responsiveness. They'll get it eventually.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
With Microsoft products, failure is not an option --
it's a standard component.
Choose your life. Choose your future. Derek Glidden
Choose Linux. http://www.illusionary.com/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:33:21 EDT