Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1373827

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

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: sched: horrible way to detect whether a task has been preempted Jessica Yu <jeyu@redhat.com> - 2016-04-07 23:20 +0200
  Re: sched: horrible way to detect whether a task has been  preempted Jiri Kosina <jikos@kernel.org> - 2016-04-07 23:40 +0200
    Re: sched: horrible way to detect whether a task has been preempted Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-08 00:40 +0200
      Re: sched: horrible way to detect whether a task has been  preempted Jiri Kosina <jikos@kernel.org> - 2016-04-08 01:00 +0200
    Re: sched: horrible way to detect whether a task has been preempted Jessica Yu <jeyu@redhat.com> - 2016-04-08 01:20 +0200
      Re: sched: horrible way to detect whether a task has been  preempted Jiri Kosina <jikos@kernel.org> - 2016-04-08 09:10 +0200
        Re: sched: horrible way to detect whether a task has been preempted Petr Mladek <pmladek@suse.com> - 2016-04-08 10:10 +0200
          Re: sched: horrible way to detect whether a task has been preempted Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-08 16:40 +0200
            Re: sched: horrible way to detect whether a task has been preempted Petr Mladek <pmladek@suse.com> - 2016-04-11 10:40 +0200

csiph-web