From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sll0u-0001MB-ON for qemu-devel@nongnu.org; Mon, 02 Jul 2012 14:06:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sll0o-0001t6-1H for qemu-devel@nongnu.org; Mon, 02 Jul 2012 14:06:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sll0n-0001sF-PE for qemu-devel@nongnu.org; Mon, 02 Jul 2012 14:06:13 -0400 From: Eduardo Habkost Date: Mon, 2 Jul 2012 15:06:32 -0300 Message-Id: <1341252398-12268-1-git-send-email-ehabkost@redhat.com> Subject: [Qemu-devel] [RFC PATCH 0/6] option to not remove files inside -mem-path dir (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Bill Gray , Andrea Arcangeli , Andre Przywara , kvm@vger.kernel.org, Bharata B Rao Resending series, after fixing some coding style issues. Does anybody has any feedback about this proposal? Changes v1 -> v2: - Coding style fixes Original cover letter: I was investigating if there are any mechanisms that allow manually pinning of guest RAM to specific host NUMA nodes, in the case of multi-node KVM guests, and noticed that -mem-path could be used for that, except that it currently removes any files it creates (using mkstemp()) immediately, not allowing numactl to be used on the backing files, as a result. This patches add a -keep-mem-path-files option to make QEMU create the files inside -mem-path with more predictable names, and not remove them after creation. Some previous discussions about the subject, for reference: - Message-ID: <1281534738-8310-1-git-send-email-andre.przywara@amd.com> http://article.gmane.org/gmane.comp.emulators.kvm.devel/57684 - Message-ID: <4C7D7C2A.7000205@codemonkey.ws> http://article.gmane.org/gmane.comp.emulators.kvm.devel/58835 A more recent thread can be found at: - Message-ID: <20111029184502.GH11038@in.ibm.com> http://article.gmane.org/gmane.comp.emulators.qemu/123001 Note that this is just a mechanism to facilitate manual static binding using numactl on hugetlbfs later, for optimization. This may be especially useful for single large multi-node guests use-cases (and, of course, has to be used with care). I don't know if it is a good idea to use the memory range names as a publicly- visible interface. Another option may be to use a single file instead, and mmap different regions inside the same file for each memory region. I an open to comments and suggestions. Example (untested) usage to bind manually each half of the RAM of a guest to a different NUMA node: $ qemu-system-x86_64 [...] -m 2048 -smp 4 \ -numa node,cpus=0-1,mem=1024 -numa node,cpus=2-3,mem=1024 \ -mem-prealloc -keep-mem-path-files -mem-path /mnt/hugetlbfs/FOO $ numactl --offset=1G --length=1G --membind=1 --file /mnt/hugetlbfs/FOO/pc.ram $ numactl --offset=0 --length=1G --membind=2 --file /mnt/hugetlbfs/FOO/pc.ram Eduardo Habkost (6): file_ram_alloc(): coding style fixes file_ram_alloc(): use g_strdup_printf() instead of asprintf() vl.c: change mem_prealloc to bool (v2) file_ram_alloc: change length argument to size_t (v2) file_ram_alloc(): extract temporary-file creation code to separate function (v2) add -keep-mem-path-files option (v2) cpu-all.h | 3 ++- exec.c | 68 +++++++++++++++++++++++++++++++++++++++++++------------ qemu-options.hx | 12 ++++++++++ vl.c | 9 ++++++-- 4 files changed, 75 insertions(+), 17 deletions(-) -- 1.7.10.4