+++ Jiri Kosina [07/04/16 23:37 +0200]:
On Thu, 7 Apr 2016, Jessica Yu wrote:
Been sort of rattling my head over the scheduler code :-) Just following
the calls in and out of __schedule() it doesn't look like there is a
current flag/mechanism to tell whether or not a task has been
preempted..
Performing the complete stack unwind just to determine whether task has
been preempted non-volutarily is a slight overkill indeed :/
Is there any reason why you didn't just create a new task flag,
something like TIF_PREEMPTED_IRQ, which would be set once
preempt_schedule_irq() is entered and unset after __schedule() returns
(for that task)? This would roughly correspond to setting the task flag
when the frame for preempt_schedule_irq() is pushed and unsetting it
just before the frame preempt_schedule_irq() is popped for that task.
This seems simpler than walking through all the frames just to see if
in_preempt_schedule_irq() had been called. Would that work?
Alternatively, without eating up a TIF_ space, it'd be possible to push a
magic contents on top of the stack in preempt_schedule_irq() (and pop it
once we are returning from there), and if such magic value is detected, we
just don't bother and claim unreliability.
Ah, but wouldn't we still have to walk through the frames (i.e. enter
the loop in patch 7/14) to look for the magic value in this approach?
That has advantages of both aproaches combined, i.e. it's relatively
low-cost in terms of performance penalty, and it's reliable (in a sense
that you don't have false positives).
The small disadvantage is that you can (very rarely, depending on the
chosen magic) have false negatives. That probably doesn't hurt too much,
given the high inprobability and non-lethal consequences.
How does that sound?
--
Jiri Kosina
SUSE Labs
