> I think you mis-read something: dev->serialize is a > different lock from driver->serialize. Only one of > them is superfluous -- though the names are similar.
I did indeed completely misread it. Having dev->serialize on my mind a lot right now, anything with "serialize" in it makes my neurons go "bing"! > Other than that, did you think this would cause any > problems with the usbfs changes you're looking at? Not any more :) > > For that matter, if dev->serialize was a rwsem, > > then contention could be reduced even further. > > I saw you did explain that suggestion in a different email, > and I've not responded to it yet. It seemed plausible on > first look, but I wanted to take a closer look at what > you said and compare to the code. I have no numbers to show that it gains anything. I may do some benchmarking... one day. > Something to keep in mind its that there's essentially a > two level locking hierarchy going on. The top level is > the device, dev->serialize, which controls whether its > config can change. Below that are the interfaces, which > get involved with the bus rwsem. > > I don't think I noticed you saying anything in conflict > with that, but I did want to point out (for the peanut > gallery if nobody else!) that root cause for some of the > complications with config changes. Now that my neurons are re-aligned, I think we are in complete agreement. All the best, Duncan. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
