Messages in this thread | | | Date | Sun, 14 Dec 2014 21:30:18 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH] sched: Fix lost reschedule in __cond_resched() |
| |
On Sun, Dec 14, 2014 at 11:50:20AM -0800, Linus Torvalds wrote: > On Sun, Dec 14, 2014 at 10:04 AM, Frederic Weisbecker > <fweisbec@gmail.com> wrote: > > > > Such as: > > So I like your patch, but quite frankly, can we go one step further? > > Look at the callers of __schedule(). > > EVERY SINGLE ONE now has that loop around it that goes along the lines of > > do { > .. disable preemption somehow .. > __schedule(); > ...enable preemption without scheduling .. > } while (need_resced()); > > except for one - the regular "schedule()" function. > > Furthermore, look inside __schedule() itself: it has the same loop, > except with a count of one. > > So I would suggest going the extra mile, and > - remove the loop from __schedule() itself
That sounds like a good idea. Unless the loop inside __schedule() is very frequent and sensitive enough to show visible overhead if we force it to pass through the preemp_count_add/sub() and local_irq_*() operations in the preempt_schedule_*() functions.
I suspect it's not, so I'm cooking that patch.
> - add the same loop as everywhere else to "schedule()"
Right. I'm doing that too.
> IOW, just make this "you have to loop and disable preemption" thing be > a rule that __schedule() can depend on.
Ok. It would be nice if we could have a common function that does the loop and PREEMPT_ACTIVE increments. But the variable code is inside that loop so that's only factorizable with a function pointer (no-go in that fast-path) or a macro that would make things even worse and ugly.
So I think I'll just keep all those loops explicit.
Thanks.
> Linus
| |