From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35300 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OiXPV-0008Eu-Uk for qemu-devel@nongnu.org; Mon, 09 Aug 2010 14:49:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OiXPU-0001qI-Lk for qemu-devel@nongnu.org; Mon, 09 Aug 2010 14:49:21 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:52501) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OiXPU-0001qA-JP for qemu-devel@nongnu.org; Mon, 09 Aug 2010 14:49:20 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o79IZhGY010681 for ; Mon, 9 Aug 2010 14:35:43 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o79In5N6868414 for ; Mon, 9 Aug 2010 14:49:05 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o79In5Go013485 for ; Mon, 9 Aug 2010 14:49:05 -0400 Message-ID: <4C604D9D.5060305@linux.vnet.ibm.com> Date: Mon, 09 Aug 2010 13:49:01 -0500 From: Michael Roth MIME-Version: 1.0 Subject: Re: [Qemu-devel] Virtual memory question References: <4C6030CE.3080400@linux.vnet.ibm.com> In-Reply-To: <4C6030CE.3080400@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org On 08/09/2010 11:46 AM, Michael Roth wrote: > > 2) exec.c:file_ram_alloc() assumes you're allocating off a hugetlbfs and > makes some system calls to get the block/hugepage size. A quick hack > might be to comment out the following in exec.c:gethugepagesize(): > > if (fs.f_type != HUGETLBFS_MAGIC) > fprintf(stderr, "Warning: path not on HugeTLBFS: %s\n", path); > > You may also want to replace the mkstemp() with a mkostemp() and set > O_SYNC on the file > > But beyond hacks, I think generalizing -mempath might have some other > useful applications (using it as a way to expose tmpfs-backed/numactl'd > files as numa nodes to guests came up in an earlier discussion, and > memory compression via zram/compcache is another). > Actually I guess 2) isn't really an issue, thought was an error path but I was mistaken. -Mike