Re: sched: horrible way to detect whether a task has been preempted

[Jessica Yu]

+++ 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