2009-02-28 10:10:57     question on entry.S

2009-02-28 10:10:57     question on entry.S

Phil Wilshire (UNITED STATES)

Message: 70159   

Hi experts,

I am trying to get my poor head around the some of the magic in entry.S

This is the last part of _system_call

Is it true that interrupts are possibly left disabled for a time if we get to this code with interrupts disabled and no SIGPENDING ?

    cc = BITTST(r7, TIF_SIGPENDING);

    if !cc jump .Lsyscall_really_exit;

                   

I am looking for some interrupt latency causes.

            

regards

  Phil Wilshire

  Part of entry.S

========

.Lresume_userspace:

    r7 = sp;

    r4.l = lo(ALIGN_PAGE_MASK);

    r4.h = hi(ALIGN_PAGE_MASK);

    r7 = r7 & r4;        /* thread_info->flags */

    p5 = r7;

.Lresume_userspace_1:

    /* Disable interrupts.  */

    [--sp] = reti;

    reti = [sp++];

    r7 = [p5 + TI_FLAGS];

    r4.l = lo(_TIF_WORK_MASK);

    r4.h = hi(_TIF_WORK_MASK);

    r7 =  r7 & r4;

.Lsyscall_resched:

    cc = BITTST(r7, TIF_NEED_RESCHED);

    if !cc jump .Lsyscall_sigpending;

    /* Reenable interrupts.  */

    [--sp] = reti;

    r0 = [sp++];

    SP += -12;

    call _schedule;

    SP += 12;

    jump .Lresume_userspace_1;

.Lsyscall_sigpending:

    cc = BITTST(r7, TIF_RESTORE_SIGMASK);

    if cc jump .Lsyscall_do_signals;

    cc = BITTST(r7, TIF_SIGPENDING);

    if !cc jump .Lsyscall_really_exit;   << if we get here and branch are interrupts still disabled

.Lsyscall_do_signals:

    /* Reenable interrupts.  */

    [--sp] = reti;

    r0 = [sp++];

    r0 = sp;

    SP += -12;

    call _do_signal;

    SP += 12;

.Lsyscall_really_exit:

    r5 = [sp + PT_RESERVED];

    rets = r5;

    rts;

ENDPROC(_system_call)

QuoteReplyEditDelete

2009-02-28 10:17:15     Re: question on entry.S

Robin Getz (UNITED STATES)

Message: 70162   

Phil:

Why do you think it comes from there? What exeriments have you run?

-Robin

QuoteReplyEditDelete

2009-02-28 11:33:54     Re: question on entry.S

Phil Wilshire (UNITED STATES)

Message: 70165   

Hi Robin,

No reason to suspect this particular code extract.

I am looking for all possible reasons for extra delays in interrupt processing.

I am using the core timer to test things. my Linux is running from timer3.

I simply measure the delay on servicing the core timer interrupt.

I have done A LOT of work to never mask the core timer interrupt and

The entry to my core timer isr does not use the linux interrupt dispatcher.

I have created my own context save/restore for the core timer interrupt that does not do the normal "return_from_interrupt" exit.

The idea is to make the core timer interrupt  happen no matter what the rest of the system is doing.

It will act like a "real-time" service and do nothing to upset regular linux processing.

I have my own latency monitoring system  which I will publish in a few days

Here are some typical results BF527 2008R1.5, note that in the range 525 = 1 microsecond

=============================================================

lat name (zcore)                                                              

                                                                              

    num vals = 2048                                                           

    max val = 5271                                                            

    min val = 486                                                             

   under min val = 0                                                          

   over max val = 0 

slot              (range)          # of samples                                 

lat slot 000 (486<->786)  count 1663 **************************************** 

lat slot 001 (786<->1086)  count 305 **************************************** 

lat slot 002 (1086<->1386)  count 015 *******                                 

lat slot 003 (1386<->1686)  count 015 *******                                 

lat slot 004 (1686<->1986)  count 029 **************                          

lat slot 005 (1986<->2286)  count 020 **********                              

lat slot 006 (2286<->2586)  count 000                                         

lat slot 007 (2586<->2886)  count 000                                         

lat slot 008 (2886<->3186)  count 000                                         

lat slot 009 (3186<->3486)  count 000                                         

lat slot 010 (3486<->3786)  count 000                                         

lat slot 011 (3786<->4086)  count 000                                         

lat slot 012 (4086<->4386)  count 000                                         

lat slot 013 (4386<->4686)  count 000                                         

lat slot 014 (4686<->4986)  count 000                                         

lat slot 015 (4986<->5286)  count 001 *    

the slot 000 shows most of the interrupt latency is between 0.926 and 1.50 uSeconds, this is nice.

I am trying to catch the few 10 microsecond and more outliers

I am trying to avoid using the NMI but it may come down to that.

The application will never use any external bus so I am safe from the speculative reads.

regards

  Phil

QuoteReplyEditDelete

2009-03-01 03:58:09     Re: question on entry.S

Mike Frysinger (UNITED STATES)

Message: 70176   

the label is misleading ... it isnt disabling/enabling interrupts, it's disabling/enabling nested interrupts.  but in your case, that's probably the same thing.