do you plan to sue me as well? :)
"If redhat doesn't use the -aa VM " was a short form of "if redhat
cannot see the goodness of all the bugfixing work that happened between
the 2.4.9 VM and any current branch 2.4, and so if they keep shipping
2.4.9 VM as the best one for DBMS and critical VM apps like the SAP
benchmark".
I think it's fair enough to say that if you plan to keep shipping 2.4.9
VM with all its troubles like I understood yesterday (starting from VM
highmem deadlocks, to kswapd looping into ZONE_DMA etc..., swap storms
throwing the realistic SAP benchmark to /dev/null) that was not usable
on long uptimes on big DBMS with several gigabytes of ram.
Somebody else also complained me about this saying that from what I said
it looks like the -aa VM is the best thing possible which is obviously
not true. In such two lines I said -aa VM just to go short. The -aa VM
in 2.4.18pre2aa2 is obviously certainly not the best that you can make
and I suggest everybody to try to make things better and invent and try
new algorithm etc... that is just the best compromise that _I_ could
make so far. So it is obvious if anybody doesn't use the -aa VM in
2.4.18pre2aa2 it doesn't mean he doesn't understand about VM. as far I
can tell rmap could be an order of magnitude better of -aa VM in
2.4.18pre2aa2, it's just I didn't checked it yet (because of all the non
obvious implication the rmap design adds, see DaveM emails of one year
back to linux-mm). All my wondering in my previous email was between
2.4.9 VM with all its known troubles and a sane version of the current
vm like in 2.4.18pre2aa2. So about the past and the present, not about
the present and the future. I thought it was obvious from the context of
the email. I said this in two lines and apparently RedHat didn't like
it, I'm sorry, but quite frankly I think that was quite fair enough, at
least with this additional clarification added.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/