linux-kernel - Re: [Xen-devel] [PATCH v1][RFC] drivers/xen, balloon driver numa support in kernel

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 12 Aug 2013 19:44:09 +0100
From:	David Vrabel <david.vrabel@...rix.com>
To:	Yechen Li <lccycc123@...il.com>
CC:	<xen-devel@...ts.xen.org>, <dario.faggioli@...rix.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH v1][RFC] drivers/xen,	balloon driver numa
 support in kernel

On 12/08/13 15:13, Yechen Li wrote:
>   This small patch adds numa support for balloon driver. Kernel version: 3.11-rc5
>   It's just a RFC version, since I'm waiting for the interface of numa topology.
>   The balloon driver will read arguments from xenstore: /local/domain/(id)/memory
> /target_nid, and settle the memory increase/decrease operation on specified
> p-nodeID.

Its is difficult to review an ABI change without any documentation for
the new ABI.

I would also like to see a design document explaining the overall
approach planned to be used here.  It's not clear why explicitly
specifying nodes is preferable to (e.g.) the guest releasing/populating
evenly across all its nodes (this would certainly be better for the guest).

It seems like unless this is used carefully, all VMs will end up with
suboptimal memory layouts as they are repeatedly balloon up and down to
satisfy the whims of the latest VM being started etc.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/