From: Oleg D. <gr...@na...> - 2002-10-16 12:08:13
|
Hello! Here at NAMESYS we currently employ special patches that track spinlocks usage (checking so that every spinlock is unlocked by its owner process (except special case which is run queue unlock), double lock of spinlock by the same owner, and also unlock of not locked spinlock). Unfortunatelly all this nice stuff breaks with SMP in UML. schedule_tail() called from new_thread_handler() when you start idle threads in turn tries to unlock rq lock for its CPU, but this lock is not locked. I suspect that the problem is you should put these run queue locks to locked state prior to each idle task start. Nikita have different opinion that I do not understand yet. Debugging of that is hardened with the fact taht it seems to be impossible to attach to these newly created idle thread at the very beginning of there life, where all the actions happens. Anyway the problem is there and probably you are the best man who can resolve it (or say that this is not a problem ;) ). Any comments? Thank you. Bye, Oleg |
From: Jeff D. <jd...@ka...> - 2002-10-17 02:45:06
|
gr...@na... said: > schedule_tail() called from new_thread_handler() > when you start idle threads in turn tries to unlock rq lock for > its CPU, but this lock is not locked. Yes, that's definitely a problem. > I suspect that the problem > is you should put these run queue locks to locked state prior to > each idle task start. Nikita have different opinion that I do not > understand yet. That sounds reasonable, what does Nikita think about this? Jeff |
From: Nikita D. <Nikita@Namesys.COM> - 2002-10-17 07:33:05
|
Jeff Dike writes: > gr...@na... said: > > schedule_tail() called from new_thread_handler() > > when you start idle threads in turn tries to unlock rq lock for > > its CPU, but this lock is not locked. > > Yes, that's definitely a problem. > > > I suspect that the problem > > is you should put these run queue locks to locked state prior to > > each idle task start. Nikita have different opinion that I do not > > understand yet. > > That sounds reasonable, what does Nikita think about this? I didn't understand why this is not a problem for other architectures. All new threads start execution by unlocking rq->lock in finish_arch_switch(). > > Jeff > Nikita. |
From: Jeff D. <jd...@ka...> - 2002-10-17 16:57:59
|
Nikita@Namesys.COM said: > I didn't understand why this is not a problem for other architectures. And I still don't. init_idle locks both the current queue and the target queue to move the idle thread and then unlocks them. I don't see anything in i386 which prevents idle threads from unlocking an unlocked queue. It seems to use the default switching macros, as does UML. > All new threads start execution by unlocking rq->lock in > finish_arch_switch(). Yes, and that's called through schedule_tail. I don't see how that can be right for an idle thread, unless it has previously locked the queue. Jeff |
From: Nikita D. <Nikita@Namesys.COM> - 2002-10-17 17:07:51
|
Jeff Dike writes: > Nikita@Namesys.COM said: > > I didn't understand why this is not a problem for other architectures. > > And I still don't. init_idle locks both the current queue and the target > queue to move the idle thread and then unlocks them. I don't see anything > in i386 which prevents idle threads from unlocking an unlocked queue. > > It seems to use the default switching macros, as does UML. > Actually, current CONFIG_SPIN_DEBUG doesn't check double unlock, so it well may be that all architectures are broken. We have debugging patch that monitors such things, probably it worth being send to the LKML, after some massaging. Or may be we should just ask Ingo. :) > > All new threads start execution by unlocking rq->lock in > > finish_arch_switch(). > > Yes, and that's called through schedule_tail. I don't see how that can be > right for an idle thread, unless it has previously locked the queue. > > Jeff > Nikita. |