From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztobk-0005yy-0t for qemu-devel@nongnu.org; Tue, 03 Nov 2015 22:19:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ztobg-0004pn-TO for qemu-devel@nongnu.org; Tue, 03 Nov 2015 22:19:32 -0500 Received: from mga11.intel.com ([192.55.52.93]:32817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ztobg-0004op-ND for qemu-devel@nongnu.org; Tue, 03 Nov 2015 22:19:28 -0500 References: <1446455617-129562-1-git-send-email-guangrong.xiao@linux.intel.com> <1446455617-129562-9-git-send-email-guangrong.xiao@linux.intel.com> <20151103230026.GG4180@thinpad.lan.raisama.net> From: Xiao Guangrong Message-ID: <563977A9.3000103@linux.intel.com> Date: Wed, 4 Nov 2015 11:12:41 +0800 MIME-Version: 1.0 In-Reply-To: <20151103230026.GG4180@thinpad.lan.raisama.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v7 08/35] exec: allow memory to be allocated from any kind of path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: vsementsov@virtuozzo.com, kvm@vger.kernel.org, mst@redhat.com, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, imammedo@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, rth@twiddle.net On 11/04/2015 07:00 AM, Eduardo Habkost wrote: > On Mon, Nov 02, 2015 at 05:13:10PM +0800, Xiao Guangrong wrote: >> Currently file_ram_alloc() is designed for hugetlbfs, however, the memory >> of nvdimm can come from either raw pmem device eg, /dev/pmem, or the file >> locates at DAX enabled filesystem >> >> So this patch let it work on any kind of path >> >> Signed-off-by: Xiao Guangrong >> --- >> exec.c | 24 ++++++++++++------------ >> 1 file changed, 12 insertions(+), 12 deletions(-) >> >> diff --git a/exec.c b/exec.c >> index 9de38be..9075f4d 100644 >> --- a/exec.c >> +++ b/exec.c >> @@ -1184,25 +1184,25 @@ static void *file_ram_alloc(RAMBlock *block, >> char *c; >> void *area; >> int fd; >> - uint64_t hpagesize; >> + uint64_t pagesize; >> Error *local_err = NULL; >> >> - hpagesize = qemu_file_get_page_size(path, &local_err); >> + pagesize = qemu_file_get_page_size(path, &local_err); >> if (local_err) { >> error_propagate(errp, local_err); >> goto error; >> } >> >> - if (hpagesize == getpagesize()) { >> - fprintf(stderr, "Warning: path not on HugeTLBFS: %s\n", path); >> + if (pagesize == getpagesize()) { >> + fprintf(stderr, "Memory is not allocated from HugeTlbfs.\n"); > > If the point of this patch is to allow file_ram_alloc() to not be > specific to hugetlbfs anymore, this warning can simply go away. > > (And in case if you really want to keep the warning, I don't see the > point of the changes you made to it.) > This is the history why we did it like this: https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg02862.html Q: | What this *actually* is trying to warn against is that | mapping a regular file (as opposed to hugetlbfs) | means transparent huge pages don't work. | So I don't think we should drop this warning completely. | Either let's add the nvdimm magic, or simply check the | page size. A: | Check the page size sounds good, will check: | if (pagesize != getpagesize()) { | ...print something... |} | I agree with you that showing the info is needed, however, | 'Warning' might scare some users, how about drop this word or | just show　“Memory is not allocated from HugeTlbfs”?