On Mon, Jul 13, 2015 at 06:29:12PM +0300, Konstantin Belousov wrote: > On Mon, Jul 13, 2015 at 05:00:30PM +0200, Luigi Rizzo wrote: ... > > thanks a lot for the clarification on the intent. > > I clearly need to understand more on the architecture of the module unload. > > > > In any case: the global contention on devmtx for I/O syscalls is > > really a showstopper for making effective use of modular drivers > > so we should really find a way to remove it. > What contention do you see ? Is it on the device node for a single > device ? If yes, then any modification of the below proposal would > not help. I explained this below. It was adrian that pointed it out to me the huge devmtx contention with multiple threads doing I/O on netmap file descriptor (4-8 threads each of them issuing around 200K syscalls/s) Now i see how even if my idea of per-dev lock was correct it would not remove contention at all. One final thing: > > Is there any other way to protect access to dev->si_threadcount ? > > > > Eg how about the following: > > - use a (leaf) lock into struct cdev to protect dev->si_threadcount, so that > > we could replace dev_lock() with mtx_lock(&dev->foo) in dev_refthread(dev) > > dev_relthread(dev) and other places that access si_threadcount > This would not work, you cannot protect a lifetime of the object by a lock > contained in the object. i thought so but then the current dev_refthread() is already unsafe, accessing dev->si_flags unprotected sys/kern/kern_conf.c: struct cdevsw * dev_refthread(struct cdev *dev, int *ref) { struct cdevsw *csw; struct cdev_priv *cdp; mtx_assert(&devmtx, MA_NOTOWNED); if ((dev->si_flags & SI_ETERNAL) != 0) { *ref = 0; return (dev->si_devsw); } dev_lock(); csw = dev->si_devsw; if (csw != NULL) { cdp = cdev2priv(dev); if ((cdp->cdp_flags & CDP_SCHED_DTR) == 0) atomic_add_long(&dev->si_threadcount, 1); else csw = NULL; } dev_unlock(); *ref = 1; return (csw); } that is particularly bad though, because it prevents from checking the SI_ETERNAL flag without holding the lock (short of encoding the flag in the pointer!) cheers luigiReceived on Mon Jul 13 2015 - 16:48:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC