Messages in this thread | | | Subject | Re: [PATCH 2.6.10-mm2] Use the new preemption code [2/3] Resend | From | Thomas Gleixner <> | Date | Mon, 10 Jan 2005 14:46:09 +0100 |
| |
On Mon, 2005-01-10 at 12:02, Ingo Molnar wrote: > i wouldnt raise this issue if it was the name only, but there's more to > preempt_schedule_irq() than its name: it gets called with irqs off and > the scheduler returns with irqs off and with a guarantee that there is > no (irq-generated) pending preemption request for this task right now. > I.e. the checks for need_resched can be skipped, and interrupts dont > have to be disabled to do a safe return-to-usermode (as done on some > architectures). > > as far as i can see do_preempt_schedule() doesnt have these properties: > what it guarantees is that it avoids the preemption recursion via the > lowlevel code doing the PREEMPT_ACTIVE setting. > > lets agree upon a single, common approach. I went for splitting up > preempt_schedule() into two variants: the 'synchronous' one (called > preempt_schedule()) is only called from syscall level and has no > repeat-preemption and hence stack-recursion worries. The 'asynchronous' > one (called preempt_schedule_irq()) is called from asynchronous contexts > (hardirq events) and is fully ready to deal with all the reentrancy > situations that may occur. It's careful about not re-enabling > interrupts, etc.
Sure, I guessed that from your short description that it implies more than the seperation I have done. I have no objection against your approach at all.
tglx
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |