From: Huan Yang <link@vivo.com>
To: "Christophe JAILLET" <christophe.jaillet@wanadoo.fr>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
Cc: opensource.kernel@vivo.com
Subject: Re: [PATCH v3] udmabuf: use kmem_cache to alloc udmabuf folio
Date: Thu, 1 Aug 2024 09:39:30 +0800 [thread overview]
Message-ID: <50a3b561-5946-45b2-954e-ea95050ba459@vivo.com> (raw)
In-Reply-To: <0fbca32a-d0e9-4884-9839-be1714543398@wanadoo.fr>
在 2024/8/1 1:11, Christophe JAILLET 写道:
> [Some people who received this message don't often get email from
> christophe.jaillet@wanadoo.fr. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Le 31/07/2024 à 09:37, Huan Yang a écrit :
>> The current udmabuf_folio contains a list_head and the corresponding
>> folio pointer, with a size of 24 bytes. udmabuf_folio uses kmalloc to
>> allocate memory.
>>
>> However, kmalloc is a public pool, starting from 8,16,32 bytes.
>> Additionally, if the size is not aligned with the kmalloc size, it will
>> be rounded up to the corresponding size.
>> This means that each udmabuf_folio allocation will get 32 bytes, and
>> waste 8 bytes.
>>
>> Considering that each udmabuf creates a folio corresponding to a
>> udmabuf_folio, the wasted memory can be significant in the case of
>> memory fragmentation.
>>
>> Furthermore, if udmabuf is frequently used, the allocation and
>> deallocation of udmabuf_folio will also be frequent.
>>
>> Therefore, this patch adds a kmem_cache dedicated to the allocation and
>> deallocation of udmabuf_folio.This is expected to improve the
>> performance of allocation and deallocation within the expected range,
>> while also avoiding memory waste.
>>
>> Signed-off-by: Huan Yang <link@vivo.com>
>> ---
>> v3 -> v2: fix error description.
>> v2 -> v1: fix double unregister, remove unlikely.
>> drivers/dma-buf/udmabuf.c | 19 +++++++++++++++----
>> 1 file changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
>> index 047c3cd2ceff..c112c58ef09a 100644
>> --- a/drivers/dma-buf/udmabuf.c
>> +++ b/drivers/dma-buf/udmabuf.c
>> @@ -24,6 +24,8 @@ static int size_limit_mb = 64;
>> module_param(size_limit_mb, int, 0644);
>> MODULE_PARM_DESC(size_limit_mb, "Max size of a dmabuf, in
>> megabytes. Default is 64.");
>>
>> +static struct kmem_cache *udmabuf_folio_cachep;
>> +
>> struct udmabuf {
>> pgoff_t pagecount;
>> struct folio **folios;
>> @@ -169,7 +171,7 @@ static void unpin_all_folios(struct list_head
>> *unpin_list)
>> unpin_folio(ubuf_folio->folio);
>>
>> list_del(&ubuf_folio->list);
>> - kfree(ubuf_folio);
>> + kmem_cache_free(udmabuf_folio_cachep, ubuf_folio);
>> }
>> }
>>
>> @@ -178,7 +180,7 @@ static int add_to_unpin_list(struct list_head
>> *unpin_list,
>> {
>> struct udmabuf_folio *ubuf_folio;
>>
>> - ubuf_folio = kzalloc(sizeof(*ubuf_folio), GFP_KERNEL);
>> + ubuf_folio = kmem_cache_alloc(udmabuf_folio_cachep, GFP_KERNEL);
>> if (!ubuf_folio)
>> return -ENOMEM;
>>
>> @@ -491,11 +493,20 @@ static int __init udmabuf_dev_init(void)
>> DMA_BIT_MASK(64));
>> if (ret < 0) {
>> pr_err("Could not setup DMA mask for udmabuf device\n");
>> - misc_deregister(&udmabuf_misc);
>> - return ret;
>> + goto err;
>> + }
>> +
>> + udmabuf_folio_cachep = KMEM_CACHE(udmabuf_folio, 0);
>> + if (!udmabuf_folio_cachep) {
>> + ret = -ENOMEM;
>> + goto err;
>> }
>>
>> return 0;
>> +
>> +err:
>> + misc_deregister(&udmabuf_misc);
>> + return ret;
>> }
>>
>> static void __exit udmabuf_dev_exit(void)
>
> Hi,
>
> should a kmem_cache_destroy() be also added in udmabuf_dev_exit()?
Yes, thanks for point this.
>
> CJ
>
>>
>> base-commit: cd19ac2f903276b820f5d0d89de0c896c27036ed
>
prev parent reply other threads:[~2024-08-01 1:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 7:37 Huan Yang
2024-07-31 17:11 ` Christophe JAILLET
2024-08-01 1:39 ` Huan Yang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50a3b561-5946-45b2-954e-ea95050ba459@vivo.com \
--to=link@vivo.com \
--cc=christian.koenig@amd.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=opensource.kernel@vivo.com \
--cc=sumit.semwal@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®