From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) by dpdk.org (Postfix) with ESMTP id 85F175F1D for ; Wed, 27 Feb 2019 19:02:59 +0100 (CET) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1RHxcWE125787; Wed, 27 Feb 2019 18:02:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=QgntL1XwOHUyMKXKoRyDiuh8Bw7SP/BkZc+0jO2sLuY=; b=v9H/Tp6JOYQsgfyyvq0wv3vBK7xIBObH/osPEa7GglPi/CTUNy7GzOUIlyZjq3nIU8lc PTlGpJJ0BOLGp8w23GBVods1+tyamw+sE/io6LFNv8hIEUBFX84nDemA0Cz5KpOLePuh y7b0NK5Wstn+0H72Nk6dqgkmvt0BLNB2qmQay4geJV/zeAN7LCAVEQOG9ZOOq6o/S90i SDNyeKXqr3iAHRM+VJt+kxf6q7kjJa5Z/vM2nCQZVzuaxCoorIW3SJgDzI5BIkTQHbd6 +mnbal2zmYWkm7PceUqGSJL2J3zh1vkqzRtOWkdT/gosawLlri+T/taCim10xkQQkuPN 6g== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2qtxtrvc4b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Feb 2019 18:02:58 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x1RI2vAX026710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Feb 2019 18:02:57 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x1RI2vMo007611; Wed, 27 Feb 2019 18:02:57 GMT MIME-Version: 1.0 Message-ID: Date: Wed, 27 Feb 2019 10:02:55 -0800 (PST) From: Edwin Leung Sender: Edwin Leung To: Iain Barker , "Burakov, Anatoly" , "Wiles, Keith" Cc: dev@dpdk.org References: <631579E3-02F5-4E12-8BE6-DDAC0AE2E4A7@oracle.com> <549A6EB0-6E19-460D-9BE5-52AA40003AF0@intel.com> <345EDE69-C416-405F-B88C-04EE8384D20F@oracle.com> <896AF59A-4CCF-42FE-B2D7-160C69427DD2@intel.com> <2b3d84de-f0a5-4b38-f670-6318725821ab@intel.com> In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 15.0.5101.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9180 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902270123 X-Mailman-Approved-At: Thu, 28 Feb 2019 11:38:42 +0100 Subject: Re: [dpdk-dev] Question about DPDK hugepage fd change X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 18:03:00 -0000 Hi Anatoly, In my test for DPDK 18.11, I notice the following: 1. Using --legacy-mem switch, DPDK still opens 1 fd/huge page. In essence,= it is the same with or without this switch. 2. Using --single-file-segments does reduce the open fd to 1. However, for= each huge page that is in-use, a .lock file is opened. As a result, it st= ill uses up a large number of fd's. Thanks. -- edwin -----Original Message----- From: Iain Barker=20 Sent: Wednesday, February 27, 2019 8:57 AM To: Burakov, Anatoly ; Wiles, Keith Cc: dev@dpdk.org; Edwin Leung Subject: RE: [dpdk-dev] Question about DPDK hugepage fd change Original Message from: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]= =20 >I just realized that, unless you're using --legacy-mem switch, one=20 >other way to alleviate the issue would be to use --single-file-segments=20 >option. This will still store the fd's, however it will only do so per=20 >memseg list, not per page. So, instead of 1000's of fd's with 2MB=20 >pages, you'd end up with under 10. Hope this helps! Hi Anatoly, Thanks for the update and suggestion. We did try using --single-file-segmen= ts previously. Although it lowers the amount of fd's allocated for tracking= the segments as you noted, there is still a problem. It seems that a .lock file is created for each huge page, not for each segm= ent. So with 2MB pages the glibc limit of 1024 fd's is still exhausted quic= kly if there is ~2GB of 2MB huge pages. Edwin can provide more details from his testing. In our case much sooner, a= s we already use >500 fd's for the application, just 1GB of 2MB huge pages = is enough to hit the fd limit due to the .lock files. Thanks.