From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 37230A0542; Tue, 5 Jul 2022 07:05:02 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9E1B4021D; Tue, 5 Jul 2022 07:05:01 +0200 (CEST) Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by mails.dpdk.org (Postfix) with ESMTP id D3220400D7 for ; Tue, 5 Jul 2022 07:05:00 +0200 (CEST) Received: by mail-qt1-f182.google.com with SMTP id h19so12245089qtp.6 for ; Mon, 04 Jul 2022 22:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emumba-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CSFfE7BvJ6kGnD1a3VyZajLw/FmnhwvQvWlNGfRrWxk=; b=kuCXDmtD2urbABpqz5gwaoww5xpAykUF9seUg5yvrmau4dzVRGpuSEDsC+TDGWfniB Cg6XOag0qEokFUCm97ZtDCqRa6YuKH6r2YzGpy0Y02FTFdLdTrsmRPMGSwec7hZ2TkU0 YVPtiPtRxae4a3qNyxtb+8oELaiCco7Zko+/pIOukulj/RfHKkCeerdL8EkUvDgiBmjT Bnn9zpnATnX4gkSyqp9scCCuVGmDlp2mrmzBZxf1SODB37S1oSXYsuFkw1UrhoDk+jMW 3jBQhbIhvKHPVtGnUQNEt/PI9VaUMRmRoPzOBIA/BkjhFW49p5BLFpTFHTZ5NA461pE7 8Lrg== 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=CSFfE7BvJ6kGnD1a3VyZajLw/FmnhwvQvWlNGfRrWxk=; b=FAYgDXxfBPH82Fdg66vWMdkRQazBVxlfxXrKdPuT4HzDvcHAhFehuQXISfoaeXhq58 Ofva2HZ4MlmPJBd7fYB+hJTJnWmMU+cNhYhDgiCe1a3Rp16+5gr/jToVwr4g1cVIbKrh 3S3LO9fwraDuy9JvB4yOgDxQ/v/Y2lH6eaDvGovMnY4ZWHqXMBRQ7CEWj2bXlcbKaMJ5 TvMekbM9eEV+Qct8ylyPFoC745BcRtZLiE8DcM33s1kKwy1Y1NqDau9qLkvmqSRK81KZ eJT3uSSvd3RBMmpWX4V5OBm7oEvVxVtCsZaF0efzPQiUVzD33p5V22v8BsK4IBVMuhcq 3O8g== X-Gm-Message-State: AJIora9gAUead1iWjW6CvyulEmVELLYLFJ/QVwhZ9MZ8Utu1laD1ifWw jkM8GV8pngO7KsNBhBx5jpAbxwaxD4piSJafPAi/ X-Google-Smtp-Source: AGRyM1vdAL2floZuulXy01fBGFrewZrRURzd0XQYLrhD1XmSJ1rfD9hqD+mtBZ95mklh8LlV962grLYD/qqmaVIWQqk= X-Received: by 2002:ac8:7f0c:0:b0:317:c8f9:bed with SMTP id f12-20020ac87f0c000000b00317c8f90bedmr26244769qtk.448.1656997500230; Mon, 04 Jul 2022 22:05:00 -0700 (PDT) MIME-Version: 1.0 References: <20220525051837.247255-1-fidaullah.noonari@emumba.com> In-Reply-To: From: Fidaullah Noonari Date: Tue, 5 Jul 2022 10:04:49 +0500 Message-ID: Subject: Re: [PATCH] eal: fixes the bug where rte_malloc() fails to allocates memory To: Dmitry Kozlyuk Cc: Anatoly Burakov , dpdk-dev Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Dmitry, > alloc_sz = RTE_ALIGN_CEIL(RTE_ALIGN_CEIL(elt_size, align) + > MALLOC_ELEM_OVERHEAD, pg_sz); > I am submitting a patch regarding this > 2. Alignment calculation depends on whether we allocated new pages or not: > > malloc_heap_alloc_on_heap_id(align = 0) -> > heap_alloc(align = 1) -> > find_suitable_element(align = RTE_CACHE_LINE_ROUNDUP(align)) > > malloc_heap_alloc_on_heap_id(align = 0) -> > alloc_more_mem_on_socket(align = 1) -> > try_expand_heap() -> ... -> > alloc_pages_on_heap(align = 1) -> > find_suitable_element(align = 1) I saw alloc_pages_on_heap() has a rollback if find_suitable_element() fails to find element. Now if we remove find_suitable_element(), don't we need to rollback, wouldn't it mean unnecessary allocation or is it handled somewhere that I didn't understand. On Sat, Jun 18, 2022 at 4:29 PM Dmitry Kozlyuk wrote: > > Hi Fidaullah, > > Thanks for the fix, > Acked-by: Dmitry Kozlyuk > > > Anatoly, I noticed a couple of other things while testing this. > > 1. Consider: > > elt_size = pg_sz - MALLOC_ELEM_OVERHEAD > rte_malloc(align=0) which is converted to align = 1. > > Obviously, such an element fits into one page, however: > > alloc_sz = RTE_ALIGN_CEIL(1 + pg_sz + > (MALLOC_ELEM_OVERHEAD - MALLOC_ELEM_OVERHEAD), > pg_sz) == 2 * pg_sz. > > This can unnecessarily hit an allocation limit from the system or EAL. > I suggest, in both places: > > alloc_sz = RTE_ALIGN_CEIL(RTE_ALIGN_CEIL(elt_size, align) + > MALLOC_ELEM_OVERHEAD, pg_sz); > > This would be symmetric with malloc_elem_can_hold(). > > 2. Alignment calculation depends on whether we allocated new pages or not: > > malloc_heap_alloc_on_heap_id(align = 0) -> > heap_alloc(align = 1) -> > find_suitable_element(align = RTE_CACHE_LINE_ROUNDUP(align)) > > malloc_heap_alloc_on_heap_id(align = 0) -> > alloc_more_mem_on_socket(align = 1) -> > try_expand_heap() -> ... -> > alloc_pages_on_heap(align = 1) -> > find_suitable_element(align = 1) > > Why do we call find_suitable_element() directly and not just return > and repeat the heap_alloc() attempt?