public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: "David Wang" <00107082@163.com>
To: "Greg KH" <gregkh@linuxfoundation.org>,
	oneukum@suse.com, mathias.nyman@intel.com
Cc: 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 23:34:33 +0800 (CST)	[thread overview]
Message-ID: <69909e94.a8db.196f37b69fb.Coremail.00107082@163.com> (raw)
In-Reply-To: <5d02ca20.a42f.196f3251196.Coremail.00107082@163.com>

At 2025-05-21 22:00:14, "David Wang" <00107082@163.com> wrote:
>
>When looking in codes, I notice xen-hcd have already implemented a mempool, for example:
>drivers/usb/host/xen-hcd.c
>1323 static int xenhcd_urb_enqueue(struct usb_hcd *hcd, struct urb *urb
>...
>1334         urbp = kmem_cache_zalloc(xenhcd_urbp_cachep, mem_flags);
>1335         if (!urbp)
>1336                 return -ENOMEM;
>1337 
>1338         spin_lock_irqsave(&info->lock, flags);
>1339 
>1340         urbp->urb = urb;
>1341         urb->hcpriv = urbp;
>1342         urbp->req_id = ~0;
>
>But most others still use kzalloc.   
>Between kmem_cache and a mem slot in URB, I want say the mem slot in URB is managed more efficiently/balanced,
>and would it be  healthy to add kmem_cache in each hcds as they see the needs, we would have separated kmem_cache
>everywhere.
>
>
>Thanks
>David

hcds found using kmem_cache  for hc private data:

./drivers/usb/dwc2/hcd.c:		hsotg->desc_gen_cache = kmem_cache_create("dwc2-gen-desc",
./drivers/usb/dwc2/hcd.c:		hsotg->desc_hsisoc_cache = kmem_cache_create("dwc2-hsisoc-desc",
./drivers/usb/dwc2/hcd.c:		hsotg->unaligned_cache = kmem_cache_create("dwc2-unaligned-dma",
./drivers/usb/isp1760/isp1760-hcd.c:	urb_listitem_cachep = kmem_cache_create("isp1760_urb_listitem",
./drivers/usb/isp1760/isp1760-hcd.c:	qtd_cachep = kmem_cache_create("isp1760_qtd",
./drivers/usb/isp1760/isp1760-hcd.c:	qh_cachep = kmem_cache_create("isp1760_qh", sizeof(struct isp1760_qh),
./drivers/usb/host/uhci-hcd.c:	uhci_up_cachep = kmem_cache_create("uhci_urb_priv",
./drivers/usb/host/xen-hcd.c:	xenhcd_urbp_cachep = kmem_cache_create("xenhcd_urb_priv",

I think those hcds have already considered the high frequency of memory allocation for private data  as an issue and
address it via a const sized memory pool..
xhci could not follow this pattern since it needs a variable length memory.
But is this a good pattern to follow? A single slot of memory in URB can handle all those request.


Thanks
David
  


  reply	other threads:[~2025-05-21 15:35 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
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 [this message]
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=69909e94.a8db.196f37b69fb.Coremail.00107082@163.com \
    --to=00107082@163.com \
    --cc=gregkh@linuxfoundation.org \
    --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