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

Document created by Aaronwu Employee on Aug 14, 2013
Version 1Show Document
  • View in full screen mode

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.

Attachments

    Outcomes