From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <users-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EB4C6A0C4C for <public@inbox.dpdk.org>; Tue, 5 Oct 2021 17:56:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D8D5A413D6; Tue, 5 Oct 2021 17:56:30 +0200 (CEST) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by mails.dpdk.org (Postfix) with ESMTP id E4927413D4 for <users@dpdk.org>; Tue, 5 Oct 2021 17:56:28 +0200 (CEST) Received: by mail-io1-f42.google.com with SMTP id r75so24870977iod.7 for <users@dpdk.org>; Tue, 05 Oct 2021 08:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2BBccCH7WVQlgYGHYlTbtZZ7/6HuAXVGRKxnikdXyaI=; b=hlB7HWBKZiFVsahMfHG1qRKQA+gHpjb/rbcXf0iuV+meyEEVMrQCMviajf2ohSH0oi PLW1tWmGVg6WQPU3r89HjDJ5UIV1Iol1uJyZYboNXldIUOEXbpvVVHdmdUcXqPuaHwwY TCCIbrhTx7r1NDld1e195kok2w4S/HWLFay8QlXWA72Dzk3NVWZMPNt/xfPVY8JAVBOh G96dwNes722wCRJtdtTka8OnyaWtajLQtnwhff9Ln1hY0rgHxUHo5Zt0Svriryi+bLn7 JLOc/rwAQJ5U98WUrlarIcDvszNMOEsPnIZSSaLXvb8UTR7nkfoqOzxYZ7vzoVkvSUrO e0ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2BBccCH7WVQlgYGHYlTbtZZ7/6HuAXVGRKxnikdXyaI=; b=Vc85DtY6y2F/JtgzYhT1cvWPa/9uXwCNO0vDWgYo0w9hceBsdCUyQHjxSmd0kekz3X WKm21KojX/3bG4iHBtEt7sZpiwcob01UHEEmCo4Ff3fJ9AdUIF4RwiVpOv4CMwN4o9qv eX9wLh0uITwCiCc1+EJIsf/QW87RJe+6wZWpo87JFtloysTjmr2xwlYEgC+7C+0vkh5J Co2SMgKwmfne/X1ERpQ6dJAEyF6bYtRvrVs7XIAvZofDYdeaZoq47Yt5X+kqef0en4Ac VNF7nPoY8Ov8r4rh4d2w9Kak/Xy2sCvy2vQLstWMTOTbbQmShg2DIe9yMXZDggL9dIuJ l5og== X-Gm-Message-State: AOAM5324Cq7X+PbKQqtBtOvO2hWyh4Tb3+U5o9qLyOsT3OaEo+O2REV6 qbAQ4T7pTfTSjoCKsG5pKMUueCZrFDgJ0TS23gmp1vrR4Co= X-Google-Smtp-Source: ABdhPJzgMd0aJ8X1eZUqfLYtO2L38GaHhaHrpvXwHEwEi5ls+lHVSrZrLqucs+2qjHYYWr8UbP2YU1O1kpl77NgtbCU= X-Received: by 2002:a02:b902:: with SMTP id v2mr3239140jan.49.1633449388308; Tue, 05 Oct 2021 08:56:28 -0700 (PDT) MIME-Version: 1.0 References: <CAJxJ_jgsN+PHbBtY8Ju5V5xm2NGQwNNtfw9PJScfVs9thZmzuw@mail.gmail.com> <3927535.NYFkNA2spg@thomas> <PH0PR11MB5093B5D0808FA9C81FFB99D3F7A99@PH0PR11MB5093.namprd11.prod.outlook.com> <7391021.896Q4A1nnV@thomas> <PH0PR11MB50935FEA5233F5DC875B99A3F7A99@PH0PR11MB5093.namprd11.prod.outlook.com> In-Reply-To: <PH0PR11MB50935FEA5233F5DC875B99A3F7A99@PH0PR11MB5093.namprd11.prod.outlook.com> From: Jiany Wu <wujianyue000@gmail.com> Date: Tue, 5 Oct 2021 23:56:17 +0800 Message-ID: <CAJxJ_jhC-TcTuNsuntDZGGj8aR0QOaG0XzXN8WQpHgKm9s6TsA@mail.gmail.com> Subject: Re: [dpdk-users] can we reserve hugepage and not release To: "Burakov, Anatoly" <anatoly.burakov@intel.com> Cc: "Mcnamara, John" <john.mcnamara@intel.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, Thomas Monjalon <thomas@monjalon.net>, "dmitry.kozliuk@gmail.com" <dmitry.kozliuk@gmail.com>, "olivier.matz@6wind.com" <olivier.matz@6wind.com>, "stephen@networkplumber.org" <stephen@networkplumber.org>, "users@dpdk.org" <users@dpdk.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions <users.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/users>, <mailto:users-request@dpdk.org?subject=subscribe> Errors-To: users-bounces@dpdk.org Thanks for your explanation. Will try in memory mode.;) Burakov, Anatoly <anatoly.burakov@intel.com>=E4=BA=8E2021=E5=B9=B49=E6=9C= =8829=E6=97=A5 =E5=91=A8=E4=B8=89=E4=B8=8B=E5=8D=888:40=E5=86=99=E9=81=93= =EF=BC=9A > > -----Original Message----- > > From: Thomas Monjalon <thomas@monjalon.net> > > Sent: Wednesday, September 29, 2021 12:11 PM > > To: Jiany Wu <wujianyue000@gmail.com>; Burakov, Anatoly > > <anatoly.burakov@intel.com> > > Cc: users@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>; > > olivier.matz@6wind.com; dmitry.kozliuk@gmail.com; > > stephen@networkplumber.org; Mcnamara, John > > <john.mcnamara@intel.com> > > Subject: Re: [dpdk-users] can we reserve hugepage and not release > > > > 29/09/2021 12:16, Burakov, Anatoly: > > > From: Thomas Monjalon <thomas@monjalon.net> > > > > 18/09/2021 04:37, Jiany Wu: > > > > > Hello, > > > > > > > > > > I met a scenario that, need to start and stop the container many > > > > > times for the hugepage. But after several times container start > > > > > and stop, the hugepage is not able to reserve. > > > > > Hugepage size is 2MB, and HW only support 2MB, can't support 1GB. > > > > > Is there anyway to make sure the hugepage is still kept continuou= s? > > > > > Thanks indeed. > > > > > > > > Interesting question. > > > > I think we need to address it in the DPDK documentation. > > > > > > > > Anatoly, Stephen, Bruce, any advice please? > > > > > > > > > > Hi, > > > > > > From description, I don't quite understand what's the issue here. Is > the > > problem about "contiguousness of memory", or is it about inability to > reserve > > more hugepages? > > > > I think the issue is that sometimes some pages are not properly > released, so > > we cannot reserve them again. > > That's something I experienced myself. > > Any trick to reset hugepages state? > > [[AB]] > Under normal circumstances, the hugepage files would just be deleted and > recreated the next time a primary process initializes even if there are > leftover pages. > > That said, assuming the pages are not "released" because DPDK has left a > few files behind and a new container doesn't have permissions to delete > them (or can't for some other reason), then there is very little DPDK can > do other than track down all memory leaks. For example, using RX callback > feature is intentionally causing a memory leak because by default the API > will not free the callback structure as we cannot guarantee that there ar= e > no Dataplane threads still using that structure. Individual > drivers/libraries might also leak memory due to e.g. secondary process > usage. For example, in the general case, if something is meant to be shar= ed > by primary and secondary, but primary cannot free() it because it might > still be used by secondaries, and secondaries have no way of verifying > whether the resource is being used by other processes, or can be freed. > > Put it simply, sometimes DPDK may leak memory either out of necessity, or > even intentionally, to avoid potential use-after-free errors, and there's > no general way to solve this problem that I'm aware of. This is the kind = of > stuff --in-memory mode was introduced to address, as when hugepages are i= n > memory, there can never be leaks because we never touch the filesystem in > the first place, so if there is a recommended way to address this at all, > it would be --in-memory mode. > > > > > > How are hugepages assigned to your container? > > > Have you tried using --in-memory mode? > > > > > >