Messages in this thread | | | Date | Thu, 7 Apr 2016 19:15:13 -0400 | From | Jessica Yu <> | Subject | Re: sched: horrible way to detect whether a task has been preempted |
| |
+++ 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 >
| |