RE: [RFC] non-preemptible kernel socket for RAMster

From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
Subject: RE: [RFC] non-preemptible kernel socket for RAMster

quoted

-----Original Message-----
From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]

quoted

From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]

quoted

From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]

quoted

How often are you going to re-size your remote-SWAP?

is "as often as the working set changes on any machine in the
cluster", meaning *constantly*, entirely dynamically!  How
about a more specific example:  Suppose you have 2 machines,
each with 8GB of memory.  99% of the time each machine is
chugging along just fine and doesn't really need more than 4GB,
and may even use less than 1GB a large part of the time.
But very now and then, one of the machines randomly needs
9GB, 10GB, maybe even 12GB  of memory.  This would normally
result in swapping.  (Most system administrators won't even
have this much information... they'll just know they are
seeing swapping and decide they need to buy more RAM.)

Ok, I understand there is interest in implementing
'remote-volatile-ballooning-variant' but how do you pick a remote
candidate(hypervisor)? Let's say, memory could be available on remote
system but what if the remote-p{NIC,CPU} is overloaded? Sure, sysadmins
won't have this info because this so dynamic(and it's quite possible as
you mentioned above). But does the trans-remote-API know about this
resource-availability before opening a remote-channel?

Stressing the remote-p{NIC/CPU} might trick hypervisor-vmotion-plugin to
vmotion VM[s] to another hypervisor. How is trans-remote-API integrating
with remote/global vmotion policies to avoid this false vmotion?

Hi Chetan --

Thanks for the continued discussion.

First, let me clarify that RAMster does not depend on virtualization.
At some time in the future, it may be a nice addition for KVM*,
but the version I am developing currently only works on a
cluster of physical machines.  So vmotion/migration is not
an issue right now


As for choosing the remote machine, another key feature of
the Transcendent Memory mechanism is that any and every page
can be rejected.  If rejected, the page remains local.  In
essence, on *every* page-to-be-swapped, machine A *asks*
machine B, "can you take this page"?  If the answer is no,
machine A can choose another machine (C), or may choose to
swap the page to its own slow swap disk.  (Currently,
only the latter is implemented, but more complicated
policy could certainly be implemented.)

Dan

* Xen doesn't have drivers so RAMster-over-network is not an option
for Xen.  A future RAMster-over-exofabric might work with Xen though.)
And, by the way, the Transcendent Memory implementation on Xen
does handle vmotion/migration so it is a solvable problem.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>