From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id C3A685A90 for ; Wed, 18 May 2016 11:38:38 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id a17so70074020wme.0 for ; Wed, 18 May 2016 02:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dqiSytTkn/nZqXTAiOPdL+wcIC4OtIZBYdigyho/3/8=; b=chQO+qPYIV2GTm3fKQR7XNqMPN8z4XiIENfbdkI+WVV6hw9b441JLnRCnsDrFVi6cb PaYAFuv94C7yGIwJyUoyeZfHKkzzC8cnf0dZ8xTzwCsGjxYGCKjjlJrksdPxQNUNrvTW s9cM+3fzIpsctYAQSS3gg1DPgtxfBvb0tbnez9MMToNEv9PkIzJxCSVvdpQ02LeqZINW zuiHZ2CdLoMy7vpgfJpLGVuE7PKn2wOJ1Hx2HETlI+H/3qzmubQxmenDozgk8ZY29iGe wT+6NIJMvtketpgmmsyWpX5EJyK81IW+ttx3TEUkI2paMw9N/IZQDNOOvh+BolJ1HZBj ABZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dqiSytTkn/nZqXTAiOPdL+wcIC4OtIZBYdigyho/3/8=; b=Xuli0IHSVumeM1/ZR7pC/SUh2uYNtCPnxroswlrf81v7L81dk5lBPOipGJnG75LBHT skHyTb4U3hpsASOstQ2ALWMfF1Wq8SliZ9dJoUtSq20uZofCjnxQ9Z2UL+P0+rAXt0A4 7skWC+9lte/96Hp7cBAe4PCvy6wrVtXdQwOCgieei2wNEHJm1uFr3jgKp+Wb5l5JQHYr vroBJ9zE3IcFQA57DXbsdiljOUn4x70rx3MNd3T053VoB7E3NkTVRPbPyin+YjUd8pxC nZv2j+T+MBCp9/uxgDHXJBHIMCBRN+cZBv7VF2vqpUZ6Asw0Ad7oqOs88nkFzleNGCPa lO+g== X-Gm-Message-State: AOPr4FXYWzcZXYiHNtPIuoxjDTU8PhRY1b6l40HnINCUh0JglmmohdF6UIIuJsl53FdorJQSckK9eDhbfkO/4Z9m X-Received: by 10.194.228.102 with SMTP id sh6mr6582626wjc.173.1463564318566; Wed, 18 May 2016 02:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.16.2 with HTTP; Wed, 18 May 2016 02:38:18 -0700 (PDT) In-Reply-To: <63ae23d7-7ca3-46e5-cfc1-1a6684395428@intel.com> References: <1457089092-4128-1-git-send-email-jianfeng.tan@intel.com> <1463013881-27985-1-git-send-email-jianfeng.tan@intel.com> <1671292.hQI6ccxuUZ@xps13> <63ae23d7-7ca3-46e5-cfc1-1a6684395428@intel.com> From: David Marchand Date: Wed, 18 May 2016 11:38:18 +0200 Message-ID: To: Sergio Gonzalez Monroy Cc: Thomas Monjalon , Jianfeng Tan , "dev@dpdk.org" , Neil Horman Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCH v4] eal: make hugetlb initialization more robust 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, 18 May 2016 09:38:38 -0000 On Wed, May 18, 2016 at 10:06 AM, Sergio Gonzalez Monroy wrote: > On 17/05/2016 17:40, Thomas Monjalon wrote: >> >> 2016-05-12 00:44, Jianfeng Tan: >>> >>> This patch adds an option, --huge-trybest, to use a recover mechanism to >>> the case that there are not so many hugepages (declared in sysfs), which >>> can be used. It relys on a mem access to fault-in hugepages, and if fails >> >> relys -> relies >> >>> with SIGBUS, recover to previously saved stack environment with >>> siglongjmp(). >>> >>> Besides, this solution fixes an issue when hugetlbfs is specified with an >>> option of size. Currently DPDK does not respect the quota of a hugetblfs >>> mount. It fails to init the EAL because it tries to map the number of >>> free >>> hugepages in the system rather than using the number specified in the >>> quota >>> for that mount. >> >> It looks to be a bug. Why adding an option? >> What is the benefit of the old behaviour, not using --try-best? > > > I do not see any benefit to the old behavior. > Given that we need the signal handling for the cgroup use case, I would be > inclined to use > this method as the default instead of trying to figure out how many > hugepages we have free, etc. +1 -- David Marchand