From: Oliver Neukum <oliver@neukum.org>
To: Duncan Sands <baldrick@free.fr>, Greg KH <greg@kroah.com>
Cc: linux-usb-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Frederic Detienne <fd@cisco.com>
Subject: Re: [linux-usb-devel] [PATCH 1/9] USB usbfs: take a reference to the usb device
Date: Sun, 18 Apr 2004 15:57:58 +0200 [thread overview]
Message-ID: <200404181557.59143.oliver@neukum.org> (raw)
In-Reply-To: <200404181136.32308.baldrick@free.fr>
> > > gives correctness, but at the cost of a probable performance hit. In
> > > later steps we can (1) turn dev->serialize into a rwsem
> >
> > Rwsems are _slower_ in the normal case of no contention.
>
> Right, but remember that dev->serialize is per device, not per interface.
> So if two programs grab different interfaces of the same device using
> usbfs, or if multiple threads in the same program beat on the same
> interface, then they could lose time fighting for dev->serialize when in
> fact they could run in parallel. Personally I doubt it matters much, but
> since most of usbfs only requires read access to the data structures
> protected by dev->serialize, it seems logical to use a rwsem.
Multiple interfaces are uncommon. Devices with several interfaces bound
to usbfs are uncommoner. Concurrent use is still uncommoner. You are
slowing the common case.
> > > (2) push the acquisition of dev->serialize down to the lower levels as
> > > they are fixed up.
> >
> > Why?
>
> Efficiency. The main reason is that the copy to/from user calls are inside
> the locked region :) As for the other places where the lock could be
> dropped, I guess measurement is required to see if it gains anything.
OK. I see. But IMHO usbfs is not written for speed anyway, so don't
worry too much.
Regards
Oliver
next prev parent reply other threads:[~2004-04-18 13:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-14 10:29 [PATCH 1/9] USB usbfs: take a reference to the usb device Duncan Sands
2004-04-17 20:17 ` [linux-usb-devel] " Duncan Sands
2004-04-17 20:33 ` Oliver Neukum
2004-04-18 9:35 ` Duncan Sands
2004-04-18 13:57 ` Oliver Neukum [this message]
2004-04-18 14:08 ` Duncan Sands
2004-04-18 14:40 ` Alan Stern
2004-04-19 17:25 ` David Brownell
2004-04-23 23:18 ` Greg KH
2004-04-26 14:05 ` Duncan Sands
2004-04-26 22:14 ` Greg KH
2004-04-27 8:58 ` [linux-usb-devel] " Oliver Neukum
2004-04-30 9:04 ` Duncan Sands
2004-05-01 23:01 ` Greg KH
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=200404181557.59143.oliver@neukum.org \
--to=oliver@neukum.org \
--cc=baldrick@free.fr \
--cc=fd@cisco.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
/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