All of lore.kernel.org
 help / color / mirror / Atom feed
* entry_32.S ret_from_intr and invocation of scheduler, v3.2-rt
@ 2013-03-15 15:16 notgeorge burns
  2013-03-15 21:36 ` Thomas Gleixner
  0 siblings, 1 reply; 4+ messages in thread
From: notgeorge burns @ 2013-03-15 15:16 UTC (permalink / raw)
  To: linux-rt-users

Hello,

In branch v3.2-rt, in entry_32.S, ret_from_intr, lines 347-351, it
appears to be the case that a hard irq request can return to a
userspace task without invoking the scheduler.

What if the hardirq handler scheduled something higher priority than
the userspace task that was interrupted?  For example, suppose you
have the following scenario:

1) process A running at priority 60 in userspace.

2) hard interrupt fires, resulting in entry_32.S common_interrupt processing.

3) hard interrupt handler schedules task B via irq_wake_thread() in
kernel/irq/handle.c, i.e. wake_up_process().

4) Task B is of course the softirq for the interrupt.

5) The process/task B to be woken up has priority 70.

6) Hard interrupt handler continues to ret_from_intr to prepare for
whatever is next.

7) What is the intended behavior at line 350 of entry_32.S on branch
3.2-rt?  I.e. should we jump to work_pending, heading towards the
scheduler, or instead pass through to restore_all and return back to
process A?

Does the hardirq handler need to do something to make the TI_flags
work properly against _TIF_WORK_MASK ?   _TIF_WORK_MASK doesn't
include TIF_NEED_RESCHED so it seems that this wouldn't be the right
way to do it?

Does the hardirq handler need to do something else to cause control to
move to the higher priority softirq instead of returning to the lower
priority process?


Thank you for any clarification you can provide.
-burns

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: entry_32.S ret_from_intr and invocation of scheduler, v3.2-rt
  2013-03-15 15:16 entry_32.S ret_from_intr and invocation of scheduler, v3.2-rt notgeorge burns
@ 2013-03-15 21:36 ` Thomas Gleixner
  2013-03-17  0:10   ` notgeorge burns
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Gleixner @ 2013-03-15 21:36 UTC (permalink / raw)
  To: notgeorge burns; +Cc: linux-rt-users

On Fri, 15 Mar 2013, notgeorge burns wrote:
> Does the hardirq handler need to do something to make the TI_flags
> work properly against _TIF_WORK_MASK ?   _TIF_WORK_MASK doesn't
> include TIF_NEED_RESCHED so it seems that this wouldn't be the right
> way to do it?

To be honest I was puzzled for a second by that mysel after reading
your mail, but you got tricked by really obfuscated macro magic:

        andl $_TIF_WORK_MASK, %ecx      # is there any work to be done on
                                        # int/exception return?
        jne work_pending

So we jump to work_pending, if any bit of _TIF_WORK_MASK is set in ecx

#define _TIF_WORK_MASK                                                  \
        (0x0000FFFF &                                                   \
         ~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|                       \
           _TIF_SINGLESTEP|_TIF_SECCOMP|_TIF_SYSCALL_EMU))

So we keep everything in 0xffff _except_ _TIF_SYSCALL_TRACE,
_TIF_SYSCALL_AUDIT, _TIF_SINGLESTEP, _TIF_SECCOMP, _TIF_SYSCALL_EMU

Note the "~" before (_TIF ...... EMU) !

So _TIF_NEED_RESCHED is preserved and checked and handled in
work_pending.

You made me worried for a second, but that code has been that way for
almost a decade, so RT would have stumbled over it at some point :)

Thanks,

	tglx

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: entry_32.S ret_from_intr and invocation of scheduler, v3.2-rt
  2013-03-15 21:36 ` Thomas Gleixner
@ 2013-03-17  0:10   ` notgeorge burns
  2013-03-19 18:30     ` Steven Rostedt
  0 siblings, 1 reply; 4+ messages in thread
From: notgeorge burns @ 2013-03-17  0:10 UTC (permalink / raw)
  To: Thomas Gleixner, linux-rt-users

>> Does the hardirq handler need to do something to make the TI_flags
>> work properly against _TIF_WORK_MASK ?   _TIF_WORK_MASK doesn't
>> include TIF_NEED_RESCHED so it seems that this wouldn't be the right
>> way to do it?
>
> To be honest I was puzzled for a second by that mysel after reading
> your mail, but you got tricked by really obfuscated macro magic:
>

Ok that was a silly miss, sorry about the confusion.

Just curious, what is the rationale for irq_default_primary_handler()
not to invoke set_need_resched()?  Drivers that set up with plain-old
request_irq() will have a scheduled softirq handler, but the hardirq
will return to wherever it was without the priority of the softirq
task coming into play.  For my drivers I can work around it with
request_threaded_irq() but is the potential inversion for
request_irq()-installed handlers really the expected behavior?  Sorry
if this question has been gone over before, I couldn't find anything
with a quick search of the archives.

-burns

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: entry_32.S ret_from_intr and invocation of scheduler, v3.2-rt
  2013-03-17  0:10   ` notgeorge burns
@ 2013-03-19 18:30     ` Steven Rostedt
  0 siblings, 0 replies; 4+ messages in thread
From: Steven Rostedt @ 2013-03-19 18:30 UTC (permalink / raw)
  To: notgeorge burns; +Cc: Thomas Gleixner, linux-rt-users

On Sat, 2013-03-16 at 17:10 -0700, notgeorge burns wrote:
> Just curious, what is the rationale for irq_default_primary_handler()
> not to invoke set_need_resched()?  Drivers that set up with plain-old
> request_irq() will have a scheduled softirq handler, but the hardirq
> will return to wherever it was without the priority of the softirq
> task coming into play.  For my drivers I can work around it with
> request_threaded_irq() but is the potential inversion for
> request_irq()-installed handlers really the expected behavior?  Sorry
> if this question has been gone over before, I couldn't find anything
> with a quick search of the archives.

Why should it invoke set_need_resched(), I hope your driver isn't doing
that, as it may not get scheduled, and you just added the extra overhead
of a unnecessary schedule() call.

If a hardirq wakes up its thread, and that thread happens to be of a
higher priority than the currently running task, the act of waking up
will set need_resched for you. But it can certainly be possible for the
current userspace thread to be running at a higher priority than the
interrupt thread, and we don't want to call schedule in that case.

This is the point of -rt in the first place. Its OK to have some
userspace tasks higher priority than interrupts.

-- Steve



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-03-19 18:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-15 15:16 entry_32.S ret_from_intr and invocation of scheduler, v3.2-rt notgeorge burns
2013-03-15 21:36 ` Thomas Gleixner
2013-03-17  0:10   ` notgeorge burns
2013-03-19 18:30     ` Steven Rostedt

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.