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.