lkml.org 
[lkml]   [2016]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: sched: horrible way to detect whether a task has been preempted
    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.

    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

    \
     
     \ /
      Last update: 2016-04-08 00:02    [W:4.141 / U:0.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site