From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mukawa@igel.co.jp>
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com
 [209.85.220.53]) by dpdk.org (Postfix) with ESMTP id BB7A67E75
 for <dev@dpdk.org>; Fri, 14 Nov 2014 04:55:08 +0100 (CET)
Received: by mail-pa0-f53.google.com with SMTP id kx10so16691088pab.12
 for <dev@dpdk.org>; Thu, 13 Nov 2014 20:05:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
 :cc:subject:references:in-reply-to:content-type
 :content-transfer-encoding;
 bh=cNor+JYZaG0VsNLW5afbYkmLG67oJ46nCTJSwMp5kZI=;
 b=S4xlj7jemFaUXN14Shep1bA531SAzSgYBxtXYWt/tfL49S9ChO4TLEkxz76z3UCony
 Zj9ZDstBFO11dq6zufoeAq6partzcWwlGILa5O1b/4qIQs+8WLi2pD6mk6sV4gHl/Gaf
 WiVRN/rAmuHxi483aaz8JUxVP11ynF9eQGWuyB3ck57KZ06Y63dLNirR1m10OMyDwCMZ
 oi1eosN+GvBepesvFoUwwzsgThDma0DFDWGT8bUec8M3zb6D9jyIIBuRTtWYi5Jgtkai
 T7ShYA2RpelOh4AeVxI5YVnLY2OlsnbHYjqU5zNEl5sctn/zVxE1FTHYyirDwkcjDCzE
 8+DQ==
X-Gm-Message-State: ALoCoQkZOhLHPIG8dlfH3+D5awwSfDNUjSipGULjanKyVfO9SC9rVo3GJsVlN/LnnZECKZW7CaEp
X-Received: by 10.70.103.45 with SMTP id ft13mr7307800pdb.122.1415937909555;
 Thu, 13 Nov 2014 20:05:09 -0800 (PST)
Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132])
 by mx.google.com with ESMTPSA id bh2sm12509794pbb.12.2014.11.13.20.05.07
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Thu, 13 Nov 2014 20:05:08 -0800 (PST)
Message-ID: <54657F72.6040708@igel.co.jp>
Date: Fri, 14 Nov 2014 13:05:06 +0900
From: Tetsuya Mukawa <mukawa@igel.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Linhaifeng <haifeng.lin@huawei.com>, "Xie, Huawei" <huawei.xie@intel.com>
References: <C37D651A908B024F974696C65296B57B0F2F19EF@SHSMSX101.ccr.corp.intel.com>
 <5462DE39.1070006@igel.co.jp> <54645007.3010301@huawei.com>
 <54656950.1050204@igel.co.jp> <54657365.7090504@huawei.com>
 <546579A3.3010804@igel.co.jp>
In-Reply-To: <546579A3.3010804@igel.co.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] vhost-user technical isssues
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 03:55:09 -0000

(2014/11/14 12:40), Tetsuya Mukawa wrote:
> I am using 1GB hugepage size.
>
> $ sudo QTEST_HUGETLBFS_PATH=/mnt/huge make check
> region=0, mmap=0x2aaac0000000, size=6291456000
> region=0, munmap=0x2aaac0000000, size=6291456000, ret=-1 << failed
>
> 6291456000 is not aligned by 1GB.
> When I specify 4096MB as guest memory size, munmap() doesn't return
> error like following.
>
> $ sudo QTEST_HUGETLBFS_PATH=/mnt/huge make check
> region=0, mmap=0x2aaac0000000, size=4294967296
> region=0, munmap=0x2aaac0000000, size=4294967296, ret=0
>
>
Also I've checked mmap2 and munmap implementation of current linux kernel.
When a file on hugetlbfs is mapped, 'size' will be aligned by hugepages
size in some case.
But when munmap is called, 'size' will be aligned by PAGE_SIZE.
It mean we cannot use same 'size' value for mmap and munmap in some case.
I guess this implementation or specification cases the munmap issue.

Thanks,
Tetsuya