From: Greg KH <gregkh@linuxfoundation.org>
To: David Wang <00107082@163.com>
Cc: mathias.nyman@intel.com, oneukum@suse.com,
stern@rowland.harvard.edu, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] USB: core: add a memory pool to urb caching host-controller private data
Date: Wed, 21 May 2025 12:32:09 +0200 [thread overview]
Message-ID: <2025052148-cannot-football-74e1@gregkh> (raw)
In-Reply-To: <20250517083819.6127-1-00107082@163.com>
On Sat, May 17, 2025 at 04:38:19PM +0800, David Wang wrote:
> ---
> Changes since v2:
> 1. activat the pool only when the urb object is created via
> usb_alloc_urb()
> Thanks to Oliver Neukum <oneukum@suse.com>'s review.
Changes go below the bottom --- line, not at the top. Please read the
documentation for how to do this.
Also, these are not "threaded" together, making them hard to pick out.
Please when you resend, make them be together using git send-email or
some such tool.
> ---
> URB objects have long lifecycle, an urb can be reused between
> submit loops; The private data needed by some host controller
> has very short lifecycle, the memory is alloced when enqueue, and
> released when dequeue. For example, on a system with xhci, in
> xhci_urb_enqueue:
> Using a USB webcam would have ~250/s memory allocation;
> Using a USB mic would have ~1K/s memory allocation;
>
> High frequent allocations for host-controller private data can be
> avoided if urb take over the ownership of memory, the memory then shares
> the longer lifecycle with urb objects.
>
> Add a mempool to urb for hcpriv usage, the mempool only holds one block
> of memory and grows when larger size is requested.
>
> The mempool is activated only when the URB object is created via
> usb_alloc_urb() in case some drivers create a URB object by other
> means and manage it lifecycle without corresponding usb_free_urb.
>
> The performance difference with this change is insignificant when
> system is under no memory pressure or under heavy memory pressure.
> There could be a point inbetween where extra 1k/s memory alloction
> would dominate the preformance, but very hard to pinpoint it.
>
> Signed-off-by: David Wang <00107082@163.com>
> ---
> drivers/usb/core/urb.c | 45 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/usb.h | 5 +++++
> 2 files changed, 50 insertions(+)
>
> diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> index 5e52a35486af..53117743150f 100644
> --- a/drivers/usb/core/urb.c
> +++ b/drivers/usb/core/urb.c
> @@ -23,6 +23,8 @@ static void urb_destroy(struct kref *kref)
>
> if (urb->transfer_flags & URB_FREE_BUFFER)
> kfree(urb->transfer_buffer);
> + if (urb->hcpriv_mempool_activated)
> + kfree(urb->hcpriv_mempool);
>
> kfree(urb);
> }
> @@ -77,6 +79,8 @@ struct urb *usb_alloc_urb(int iso_packets, gfp_t mem_flags)
> if (!urb)
> return NULL;
> usb_init_urb(urb);
> + /* activate hcpriv mempool when urb is created via usb_alloc_urb */
> + urb->hcpriv_mempool_activated = true;
> return urb;
> }
> EXPORT_SYMBOL_GPL(usb_alloc_urb);
> @@ -1037,3 +1041,44 @@ int usb_anchor_empty(struct usb_anchor *anchor)
>
> EXPORT_SYMBOL_GPL(usb_anchor_empty);
>
> +/**
> + * urb_hcpriv_mempool_zalloc - alloc memory from mempool for hcpriv
> + * @urb: pointer to URB being used
> + * @size: memory size requested by current host controller
> + * @mem_flags: the type of memory to allocate
> + *
> + * Return: NULL if out of memory, otherwise memory are zeroed
> + */
> +void *urb_hcpriv_mempool_zalloc(struct urb *urb, size_t size, gfp_t mem_flags)
> +{
> + if (!urb->hcpriv_mempool_activated)
> + return kzalloc(size, mem_flags);
> +
> + if (urb->hcpriv_mempool_size < size) {
> + kfree(urb->hcpriv_mempool);
> + urb->hcpriv_mempool_size = size;
> + urb->hcpriv_mempool = kmalloc(size, mem_flags);
> + }
> + if (urb->hcpriv_mempool)
> + memset(urb->hcpriv_mempool, 0, size);
> + else
> + urb->hcpriv_mempool_size = 0;
> + return urb->hcpriv_mempool;
> +}
> +EXPORT_SYMBOL_GPL(urb_hcpriv_mempool_zalloc);
> +
> +/**
> + * urb_free_hcpriv - free hcpriv data if necessary
> + * @urb: pointer to URB being used
> + *
> + * If mempool is activated, private data's lifecycle
> + * is managed by urb object.
> + */
> +void urb_free_hcpriv(struct urb *urb)
> +{
> + if (!urb->hcpriv_mempool_activated) {
> + kfree(urb->hcpriv);
> + urb->hcpriv = NULL;
You seem to set this to NULL for no reason, AND check for
hcpriv_mempool_activated. Only one is going to be needed, you don't
need to have both, right? Why not just rely on hcdpriv being set?
And are you sure that the hcd can actually use a kmalloced "mempool"? I
don't understand why xhci can't just do this in its driver instead of
this being required in the usb core and adding extra logic and size to
every urb in the system.
thanks,
greg k-h
next prev parent reply other threads:[~2025-05-21 10:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-17 8:38 [PATCH v3 1/2] USB: core: add a memory pool to urb caching host-controller private data David Wang
2025-05-21 10:32 ` Greg KH [this message]
2025-05-21 11:25 ` David Wang
2025-05-21 12:58 ` Greg KH
2025-05-21 13:36 ` David Wang
2025-05-21 12:59 ` Greg KH
2025-05-21 14:00 ` David Wang
2025-05-21 15:34 ` David Wang
2025-05-21 12:28 ` Mathias Nyman
2025-05-21 13:23 ` David Wang
2025-05-21 13:34 ` Mathias Nyman
-- strict thread matches above, loose matches on Subject: below --
2025-05-17 8:35 David Wang
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=2025052148-cannot-football-74e1@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=00107082@163.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=oneukum@suse.com \
--cc=stern@rowland.harvard.edu \
/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;
as well as URLs for NNTP newsgroup(s).