Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18



On 9/26/06, Arnd Bergmann <arnd@xxxxxxxx> wrote:
On Monday 25 September 2006 17:39, Aubrey wrote:
> 1) Timer interrupt will call do_irq(), then return_from_int().
>
> 2) return_from_int() will check if there is interrupt pending or
> signal pending, if so, it will call schedule_and_signal_from_int().
>
> 3) schedule_and_signal_from_int() will jump to resume_userspace()
>
> 4) resume_userspace() will call _schedule to run the user task.

I have a little trouble reading your assembly code, but your
return_from_int() function should normally not call
schedule_and_signal_from_int() when the interrupt happened
in kernel context (like in the idle function):

+ /* if not return to user mode, get out */
+ p2.l = lo(IPEND);
+ p2.h = hi(IPEND);
+ r0 = [p2];
+ r1 = 0x17(Z);
+ r2 = ~r1;
+ r2.h = 0;
+ r0 = r2 & r0;
+ r1 = 1;
+ r1 = r0 - r1;
+ r2 = r0 & r1;
+ cc = r2 == 0;
+ if !cc jump 2f;

This looks a lot like you user_mode() function, so you jump
over schedule_and_signal_from_int() here.

What you described would be a preemptive kernel
(CONFIG_PREEMPT), but you clearly don't have that enabled.


No, schedule_and_signal_from_int will be called.
The above code is checking if there are at least two bits set on, if
so, schedule_and_signal_from_int will be called.

Blackfin supports 3 processor mode: (1) user mode (2) supervisor mode
(3) emulation mode. In the kernel space, the processor should be in
the supervisor mode. To keep the processor in the supervisor mode, we
raise the lowest priority interrupt event. Kerenl actually in the
interrupt handler of the lowest priority interrupt event. See
arch/blackfin/mach-bf53x/head.S.
=================================
/* This section keeps the processor in supervisor mode
* during kernel boot. Switches to user mode at end of boot.
* See page 3-9 of Hardware Reference manual for documentation.
*/

/* EVT15 = _real_start */

p0.l = lo(EVT15);
p0.h = hi(EVT15);
p1.l = _real_start;
p1.h = _real_start;
[p0] = p1;
csync;

p0.l = lo(IMASK);
p0.h = hi(IMASK);
p1.l = IMASK_IVG15;
p1.h = 0x0;
[p0] = p1;
csync;

raise 15;
p0.l = .LWAIT_HERE;
p0.h = .LWAIT_HERE;
reti = p0;
rti;
===============================================
So, in the kernel space, there is always one bit in the IPEND register
is set. And if there comes a timer interrupt event, in the timer
interrupt handler, there should be two bits set in the IPEND register.
Therefore, schedule happens in the return_from_int.

So, I still say there is no latency here.

-Aubrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • RE: Maximum frequency of re-scheduling (minimum time quantum) que stio n
    ... >interrupt will also schedule if necessary. ... >>The catch here is, without the preemptable kernel option, the kernel ... Even with the option, it can't preempt ...
    (Linux-Kernel)
  • Re: How linux schedules things when interrupts occur
    ... kernel deals with scheduling it's work. ... Suppose Linux is running on a single CPU system. ... When an APIC processed hardware interrupt comes and assuming the ... Then schedule is called and it will most likely schedule another process. ...
    (Linux-Kernel)
  • CONFIG_PREEMPT x86 assembly question
    ... Whily lazy-examining kernel code, I found the following interesting point. ... Why, after return from schedule(), first 0 is written to ... the idea of the preempt_count flag is to avoid ... causing nested interrupt while preempt_count flag is already reset. ...
    (Linux-Kernel)
  • Re: __wait_event_interruptible question
    ... > I got the next macro from sched.h from kernel 2.4.23_pre5. ... > from an interrupt service routine, I think it is possible that the ... lose the CPU before it calls schedule(). ... how it would work with preemption. ...
    (comp.os.linux.development.system)
  • Re: kernel: return from interrupt
    ... why does the kernel refuse to schedule on ... > PREEMPTION turned on in 5.x you should see the same behavior. ... > interrupt handler. ...
    (freebsd-current)