RE: [GIT PULL] mm: frontswap (for 3.2 window)

From: John Stoffel
Date: Fri Oct 28 2011 - 14:43:56 EST


>>>>> "Dan" == Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> writes:

Dan> Second, have you read http://lwn.net/Articles/454795/ ?
Dan> If not, please do. If yes, please explain what you don't
Dan> see as convincing or tangible or documented. All of this
Dan> exists today as working publicly available code... it's
Dan> not marketing material.

I was vaguely interested, so I went and read the LWN article, and it
didn't really provide any useful information on *why* this is such a
good idea.

Particularly, I didn't see any before/after numbers which compared the
kernel running various loads both with and without these
transcendental memory patches applied. And of course I'd like to see
numbers when they patches are applied, but there's no TM
(Transcendental Memory) in actual use, so as to quantify the overhead.

Your article would also be helped with a couple of diagrams showing
how this really helps. Esp in the cases where the system just
endlessly says "no" to all TM requests and the kernel or apps need to
them fall back to the regular paths.

In my case, $WORK is using linux with large memory to run EDA
simulations, so if we swap, performance tanks and we're out of luck.
So for my needs, I don't see how this helps.

For my home system, I run an 8Gb RAM box with a couple of KVM VMs, NFS
file service to two or three clients (not counting the VMs which mount
home dirs from there as well) as well as some light WWW developement
and service. How would TM benefit me? I don't use Xen, don't want to
play with it honestly because I'm busy enough as it is, and I just
don't see the hard benefits.

So the onus falls on *you* and the other TM developers to sell this
code and it's benefits (and to acknowledge it's costs) to the rest of
the Kernel developers, esp those who hack on the VM. If you can't
come up with hard numbers and good examples with good numbers, then
you're out of luck.

Thanks,
John
--
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/