Messages in this thread | | | Subject | Re: [git pull] scheduler fix | From | Peter Zijlstra <> | Date | Thu, 08 Jan 2009 08:50:53 +0100 |
| |
On Wed, 2009-01-07 at 15:47 -0800, Linus Torvalds wrote: > > On Wed, 7 Jan 2009, Ingo Molnar wrote: > > + /* > > + * Should not call ttwu while holding a rq->lock > > + */ > > + spin_unlock(&this_rq->lock); > > if (active_balance) > > wake_up_process(busiest->migration_thread); > > + spin_lock(&this_rq->lock); > > Btw, this isn't the first time we've wanted to do a wakeup while > potentially locked. > > Is there any way to perhaps go a "wake_up_gentle()" that doesn't need the > lock, and just basically does a potentially delayed wakeup by just > scheduling it asynchronously. > > That would have solved all those nasty printk issues too. These kinds of > things don't need the strict "wake up NOW" behaviour - they are more of a > "kick the dang thing and make sure it wakes up in some timely manner".
Right -- so the printk thing was solved by polling some state from the timer tick, we could make that into a list, but then you'd have to worry about memory allocation for list elements failing etc.
Same story as generic smp function call, we could do this using a self (or remote) IPI, but you'd still have the memory allocation issue -- and would need to make self-IPI work on !SMP.
I'll ponder the issue a bit more, but I'm not directly seeing anything (of course, if it were easy, we'd have done it ages ago ;-)
| |