[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1257846081.4648.11.camel@twins>
Date: Tue, 10 Nov 2009 10:41:21 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Linux Netdev List <netdev@...r.kernel.org>,
linux kernel <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC,PATCH] mutex: mutex_is_owner() helper
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists