Messages in this thread | | | Subject | Re: [RFC,PATCH] mutex: mutex_is_owner() helper | From | Peter Zijlstra <> | Date | Tue, 10 Nov 2009 10:41:21 +0100 |
| |
On Tue, 2009-11-10 at 00:21 +0100, Eric Dumazet wrote: > Peter Zijlstra a écrit : > > On Wed, 2009-11-04 at 18:19 +0100, Eric Dumazet wrote: > >> BTW, I was thinking of a mutex_yield() implementation, but could not > >> cook it without hard thinking, maybe you already have some nice > >> implementation ? > > > > Why? Yield sets off alarm bells, since 99.9%, and possibly more, of its > > uses are wrong. > > If I remember well, I had problems doing "modprobe dummy numdummies=30000", > because it creates 30000 netdevices, and thanks to hotplug starts 30000 udev > that all wait that my modprobe is finished... Nice to see load average going > so big by the way :)
lol :-) With a bit of luck udev will spawn a python interpreter for each of those things too..
> I tried following patch without success, because rtnl_unlock()/rtnl_lock() > is too fast (awaken process(es) ha(s/ve) no chance to get the lock, as we > take it immediately after releasing it)
Right, due to lock-stealing.
> diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c > index 37dcfdc..108c4fa 100644 > --- a/drivers/net/dummy.c > +++ b/drivers/net/dummy.c > @@ -138,8 +138,12 @@ static int __init dummy_init_module(void) > rtnl_lock(); > err = __rtnl_link_register(&dummy_link_ops); > > - for (i = 0; i < numdummies && !err; i++) > + for (i = 0; i < numdummies && !err; i++) { > err = dummy_init_one(); > + rtnl_unlock(); > + msleep(1); > + rtnl_lock(); > + } > if (err < 0) > __rtnl_link_unregister(&dummy_link_ops); > rtnl_unlock(); > > But if hotplug is disabled, this force a useless msleep(1) * 30000 -> this is bit slow > > Yes, this code is stupid, but I use it to stress network stack > with insane number of devices, to spot scalability problems.
Right...
> mutex_yield() could help in this situation.
Agreed, except I don't like the name, but I could be tained from sched_yield().
> mutex is said to be FIFO, but its not exactly true : A new comer can take the mutex > even if 10000 threads are waiting on mutex...
Yep, lock-stealing, you don't want to see the regression reports if you 'fix' that :-)
> I wont mention other problems, because mutex_{try}lock() has no timedwait variant
Nobody needed it I guess.. also I never quite understood the need for timedwait, either you need to get the work done or you don't, not maybe.
Use mutex_lock_interruptible() and set a timer or something.
> , and funny code doing : > > if (!rtnl_trylock()) > return restart_syscall(); > > Making 30000 processes running/fighting to get the mutex :(
Funny definition of funny ;-) That's some seriously fugly code there.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |