From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by dpdk.org (Postfix) with ESMTP id B5E628DAB for ; Wed, 30 Sep 2015 23:44:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5070; q=dns/txt; s=iport; t=1443649473; x=1444859073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=urICpvrISzQrDebybN2VvthUWa0XEcBAnu0sp+GTd9c=; b=Ip1/psi1E9Qb9q+AFy35bzCTc1/A8LXfUGAO0FP9c1KcIeFEsQ7FF+5D J9FvNOS8AujnhjpSmpAxWCAjZPh58sLrcepNfT9OJKK04Ncmmbbi9B2GX wjnCDEfcnUd5XgwclQu/eQApccoX19LfbVlsVuMXWIt0W66iiMLPoRKSc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaAgC2VgxW/4sNJK1egldNgUEGvWwBDYd0AoE5OBQBAQEBAQEBfwuEJAEBAQR5EAIBCBEDAQIoBzIUCQgCBA4FiC7MBQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLcIR8EQeELAWVeAGNEptQHwEBQoQCcYh1gQUBAQE X-IronPort-AV: E=Sophos;i="5.17,614,1437436800"; d="scan'208,217";a="192800665" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP; 30 Sep 2015 21:44:31 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t8ULiUOR005638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Sep 2015 21:44:30 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Sep 2015 16:44:30 -0500 Received: from xhc-aln-x11.cisco.com (173.36.12.85) by xch-rcd-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 30 Sep 2015 16:44:30 -0500 Received: from xmb-aln-x03.cisco.com ([169.254.6.63]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 16:44:30 -0500 From: "shesha Sreenivasamurthy (shesha)" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] Unlinking hugepage backing file after initialiation Thread-Index: AQHQ+kpckJG1vBipX0G0rq8U7ayRsJ5ThlyAgAB9RAD//6TIgIAAtHgAgAEfX4A= Date: Wed, 30 Sep 2015 21:44:29 +0000 Message-ID: References: <20150929161628.GA3810@redhat.com> <20150930003531-mutt-send-email-mst@redhat.com> In-Reply-To: <20150930003531-mutt-send-email-mst@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.36.7.18] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "Michael S. Tsirkin" Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 21:44:33 -0000 What I heard is the following: A multi-process DPDK application, working ei= ther in master-worker or master-slave fashion, can potentially benefit by k= eeping the backing files in hugetlbfs. However, it is does not work today a= s the pages are cleaned and added back when the application restarts. On th= e other hand, for a single process application there is actually no benefit= keeping the pages around. Therefore, I was wondering if we can make this configurable by passing a co= mmand line argument that will either unlink or keep the backing files. -- - Thanks char * (*shesha) (uint64_t cache, uint8_t F00D) { return 0x0000C0DE; } From: "Michael S. Tsirkin" > Date: Tuesday, September 29, 2015 at 2:35 PM To: Cisco Employee > Cc: "Xie, Huawei" >, "dev= @dpdk.org" > Subject: Re: [dpdk-dev] Unlinking hugepage backing file after initialiation On Tue, Sep 29, 2015 at 05:50:00PM +0000, shesha Sreenivasamurthy (shesha) = wrote: Sure. Then, is there any real reason why the backing files should not be unlinked ? AFAIK qemu unlinks them already. -- MST