From: Mathias Nyman <mathias.nyman@intel.com>
To: David Wang <00107082@163.com>, gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
surenb@google.com, kent.overstreet@linux.dev
Subject: Re: [RFC] USB: core/xhci: add a buffer in urb for host controller private data
Date: Tue, 13 May 2025 12:27:34 +0300 [thread overview]
Message-ID: <76b2a5ae-31b1-4627-aa59-8ff023654c3d@intel.com> (raw)
In-Reply-To: <20250512150724.4560-1-00107082@163.com>
Hi David
On 12.5.2025 18.07, David Wang wrote:
> ---
> I was checking memory allocation behaviors (via memory profiling[1]),
> when I notice a high frequent memory allocation in xhci_urb_enqueue, about
> 250/s when using a USB webcam. If those alloced buffer could be kept and
> reused, lots of memory allocations could be avoid over time.
>
> This patch is just a POC, about 0/s memory allocation in xhci with this
> patch, when I use my USB devices, webcam/keyboard/mouse.
Thanks for looking at this, this is something that obviously needs more
attention
>
> A dynamic cached memory would be better: URB keep host controller's
> private data, if larger size buffer needed for private data, old buffer
> released and a larger buffer alloced.
>
> I did not observe any nagative impact with xhci's 250/s allocations
> when using my system, hence no measurement of how useful this changes
> can make to user. Just want to collect feedbacks before putting more
> effort.
>
I think we can make a xhci internal solution that doesn't affect other hosts
or usb core.
How about adding a list of struct urb_priv nodes for every usb device, or maybe
even per endpoint? i.e. to struct xhci_virt_device or struct xhci_virt_ep.
Add size and list_head entries to struct urb_priv.
In xhci_urb_enqueue() pick the first urb_priv node from list if it exists and is
large enough, otherwise just allocate a new one and set the size.
When giving back the URB zero everything in the struct urb_priv except the size,
and add it to the list.
When the device is freed there shouldn't be any nodes left in the list, but if
there are then warn and free them.
Isoc transfers are the ones with odd urb_priv sizes. If we have a per device or
per endpoint urb_priv list then sizes will match better.
Thanks
Mathias
next prev parent reply other threads:[~2025-05-13 9:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-12 15:07 [RFC] USB: core/xhci: add a buffer in urb for host controller private data David Wang
2025-05-12 15:34 ` Alan Stern
2025-05-12 16:19 ` David Wang
2025-05-13 5:54 ` [PATCH 1/2] USB: core: add a memory pool to urb for host-controller " David Wang
2025-05-13 8:11 ` Oliver Neukum
2025-05-13 8:23 ` David Wang
2025-05-13 8:46 ` Oliver Neukum
2025-05-13 8:53 ` David Wang
2025-05-13 9:49 ` David Wang
2025-05-13 11:02 ` Oliver Neukum
2025-05-13 11:12 ` David Wang
2025-05-13 5:55 ` [PATCH 2/2] USB: xhci: use urb hcpriv mempool for " David Wang
2025-05-13 8:21 ` Oliver Neukum
2025-05-13 8:31 ` David Wang
2025-05-13 9:00 ` Oliver Neukum
2025-05-13 9:27 ` Mathias Nyman [this message]
2025-05-13 9:41 ` [RFC] USB: core/xhci: add a buffer in urb for host controller " David Wang
2025-05-13 11:38 ` [PATCH v2 1/2] USB: core: add a memory pool to urb for host-controller " David Wang
2025-05-13 14:25 ` Alan Stern
2025-05-13 14:41 ` David Wang
2025-05-13 15:37 ` Alan Stern
2025-05-13 16:35 ` David Wang
2025-05-13 18:21 ` Alan Stern
2025-05-13 18:48 ` David Wang
2025-05-13 19:46 ` Alan Stern
2025-05-14 11:27 ` Oliver Neukum
2025-05-14 6:44 ` David Wang
2025-05-14 7:29 ` Greg KH
2025-05-14 8:50 ` David Wang
2025-05-14 9:34 ` Oliver Neukum
2025-05-17 9:09 ` David Wang
2025-05-14 11:23 ` Oliver Neukum
2025-05-14 11:51 ` David Wang
2025-05-14 12:03 ` Oliver Neukum
2025-05-14 12:14 ` David Wang
2025-05-16 17:13 ` David Wang
2025-05-13 11:38 ` [PATCH v2 2/2] USB: xhci: use urb hcpriv mempool for " 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=76b2a5ae-31b1-4627-aa59-8ff023654c3d@intel.com \
--to=mathias.nyman@intel.com \
--cc=00107082@163.com \
--cc=gregkh@linuxfoundation.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=surenb@google.com \
/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