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 51D2241CB7; Fri, 17 Feb 2023 03:15:06 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E18D740EE1; Fri, 17 Feb 2023 03:15:05 +0100 (CET) Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by mails.dpdk.org (Postfix) with ESMTP id 8EA2240A8B for ; Fri, 17 Feb 2023 03:15:04 +0100 (CET) Received: by mail-qt1-f180.google.com with SMTP id m12so4200940qth.4 for ; Thu, 16 Feb 2023 18:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rHAiyDrJW3LDaZukJ0r2QfkEVkkNH4cc+qOaztMkeQc=; b=W8jkN8T3JOPRuMleBIIA3KpG5Zh3UFIEC+/SkCNv3GF9fCTPiHy8GCAtvIRhI+nlc/ ErC1BD0wKUVfkG6u2IYGPZAtApHelez4iZ47OjYrR62rgBqdEp6fRtxZweOsaiAXIbsd 3JvrnSehZiG7K4T+it0IKTRqdscqs91qQtg+lLqPVIpLJhIcdN3fW6OOsaS/TNAcoRzv caosZasJUCPyffoNkYXqXnrrronWbdmrwMup7nM4UAq0z3UBxRE1ZKBVGpjDvTLkcGxX bz+nsXJL0CGuuP7Ylo0WKDjvtj1DNuCU6CD8GC5clSyDJn8D7wiK/haOdnLnXVePfLwy Ly0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rHAiyDrJW3LDaZukJ0r2QfkEVkkNH4cc+qOaztMkeQc=; b=fbLFYNchOIYoxDMfQZEot70QJNcIzpBRn55dqqQsiQ/0tN6txrZlJ9iax48gQTC4WW tiCFuyeWHqW+zFkD2v5YzahMPIBVlOL/g82TwwsfcgNvppsnYDMOErnc7d0WY6wK0ETo xF9d0wsL7INE4Haj9AAHCtKMFRVdB2hFFQc8wrz5KYW0JgTs4NjJOu+G47YEo/MpNoW4 6GtZExz+L1JCZByWG77QfBGBVjsvQ/XbD4Y2CDceCpxevWby9Uu2VhPdy8cV+YJFEYZG RHYwiZ2ZX1+x6+hSaQoWdmECafCLxhEyDR+rA5cu1B2A6++RvHqSHB9N8VwnFQaFM9UV Z8iA== X-Gm-Message-State: AO0yUKWNaLM4hiTh6p0CPsvE731J2nDOLfKqImFcP9j07vwH20LVGXAY fWyoY4hLB8vWOSR9JBlbp7vlo9ILPgLQE7GvASrbXw== X-Google-Smtp-Source: AK7set9OBZiDc08pLug0CruuFy7fjJnvekVqA/ndd8pTS9CUMF4wxhnAVX+TMzp3A5YtJGClF7QS0dqnNY1sTr/6bds= X-Received: by 2002:ac8:5f4a:0:b0:3b8:938e:6ecb with SMTP id y10-20020ac85f4a000000b003b8938e6ecbmr602723qta.2.1676600103716; Thu, 16 Feb 2023 18:15:03 -0800 (PST) MIME-Version: 1.0 References: <20230210063022.52171-1-changfengnan@bytedance.com> <2134819.GUh0CODmnK@thomas> <98CBD80474FA8B44BF855DF32C47DC35D8773F@smartserver.smartshare.dk> In-Reply-To: From: Fengnan Chang Date: Fri, 17 Feb 2023 10:14:52 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] malloc: fix malloc performance may becomes worse as the number of malloc increases To: Liang Ma Cc: =?UTF-8?Q?Morten_Br=C3=B8rup?= , Thomas Monjalon , anatoly.burakov@intel.com, dev@dpdk.org, rsanford@akamai.com, bruce.richardson@intel.com, maxime.coquelin@redhat.com, david.marchand@redhat.com, jerinj@marvell.com, honnappa.nagarahalli@arm.com, Fidaullah Noonari Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Liang Ma =E4=BA=8E2023=E5=B9=B42=E6=9C=8816=E6=97=A5= =E5=91=A8=E5=9B=9B 22:04=E5=86=99=E9=81=93=EF=BC=9A > > On Wed, Feb 15, 2023 at 12:10:23PM +0100, Morten Br=C3=B8rup wrote: > > +CC: Fidaullah Noonari , your name also s= hows up in the git log; perhaps you can help review this patch. > > > > > > I gave up reviewing in depth, because the existing code is not easy to = quickly understand, and it would take too long for me. E.g. the malloc_elem= ->size is field is undocumented, and find_suitable_element() calls the mall= oc_elem_free_list_index() function with the raw size (as passed to the func= tion), but malloc_elem_free_list_insert() calls the malloc_elem_free_list_i= ndex() with malloc_elem->size - MALLOC_ELEM_HEADER_LEN. > > > > Looking isolated at the patch itself... > > > > I agree with the way the patch modifies the ranges of the free list, an= d the consequential removal of the "- 1" from the calculation of log2. > > > > Intuitively, the lists should cover ranges such as [0x100..0x3FF], whic= h this patch does, not [0x101..0x400], how it was previously... The ranges = with this patch make much more sense. > > > > So if the existing code is otherwise correct, i.e. handles the size wit= h/without MALLOC_ELEM_HEADER_LEN correctly, my gut feeling says this patch = is an improvement. > > > > Acked-by: Morten Br=C3=B8rup > I run the test with DPDK malloc perf test. The issue is replicated. > IMO, the whole process is if application use rte_malloc with a relative > large alignment size. e.g. 4K alignment. Currently implementation will > generate lots "fragment" because of the large alignment in related mem > element free list. In the test code, 4K malloc size + 4k alignment will > lead to the actually space is needed has to take from upper level mem > element idx free list. The consequence is that will generate lots > fragment element and those element is inserted to the current level mem > free-list. However, when the rte_malloc select which free list to start > scan with, it doesn't take the alignment into account, which ends up > with waste some time in the current level free-list. If the scan logic > take alignment into account, it might "smartly" skip current level and > jump to the upper level directly. > Thank you for the detailed explanation ! You may have already found the problem that this patch can only solve the fragmentation problem of 4k/16k/64k scenes, not work for 3k/15k/63k. For example, alloc 3k and align with 1k, also has this problem. Now this patch can't handle all similar scenarios=EF=BC=8CWe already starte= d working on a new soultion which aims to solve all similar problems . BTW, this patch is still useful, because even without fragmentation problems, the probability of finding a suitable elem from a larger size lis= t is greater than from a smaller size list. > > >