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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 6 Jul 2011 14:12:04 -0400
From:	"Loke, Chetan" <Chetan.Loke@...scout.com>
To:	"Dan Magenheimer" <dan.magenheimer@...cle.com>,
	<netdev@...r.kernel.org>
Cc:	"Konrad Wilk" <konrad.wilk@...cle.com>,
	"linux-mm" <linux-mm@...ck.org>
Subject: RE: [RFC] non-preemptible kernel socket for RAMster

> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@...cle.com]
> Sent: July 05, 2011 9:06 PM
> To: Loke, Chetan; netdev@...r.kernel.org
> Cc: Konrad Wilk; linux-mm
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
> 
> > From: Loke, Chetan [mailto:Chetan.Loke@...scout.com]
> > Subject: RE: [RFC] non-preemptible kernel socket for RAMster
> >
> > > From: Dan Magenheimer [mailto:dan.magenheimer@...cle.com]
> 
> > 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?


> Dan

Chetan Loke
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html