On Thu, Oct 9, 2014 at 6:27 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > >> +Lsignal_return: >> + ANDI32 r1, r10, _TIF_SIGPENDING | _TIF_NOTIFY_RESUME >> + beq r1, r0, restore_all >> + mov r4, sp /* pt_regs */ >> + SAVE_SWITCH_STACK >> + call do_notify_resume >> + beq r2, r0, no_work_pending >> + RESTORE_SWITCH_STACK >> + /* prepare restart syscall here without leaving kernel */ >> + ldw r2, PT_R2(sp) /* reload syscall number in r2 */ >> + ldw r4, PT_R4(sp) /* reload syscall arguments r4-r9 */ >> + ldw r5, PT_R5(sp) >> + ldw r6, PT_R6(sp) >> + ldw r7, PT_R7(sp) >> + ldw r8, PT_R8(sp) >> + ldw r9, PT_R9(sp) >> + br local_restart /* restart syscall */ >> + >> +no_work_pending: >> + RESTORE_SWITCH_STACK >> + br restore_all > > Umm... Branch to no_work_pending will be usuall taken. How well does > branch predictor on that processor cope with such things? Nios2 have implemented dynamic branch prediction. Processor will use current PC and previous history when lookup branch history table. So this mean the same location branch will mostly predict correctly if the branch is always taken or always not taken. > Another thing is the point Richard made - multiple pending signals need to be > handled. IOW, that should be a branch to ret_from_exception, not restore_all. Okay, will update this to branch to ret_from_exception. Thanks for reviewing. Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
