[lkml]   [2005]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.10-mm2] Use the new preemption code [2/3] Resend
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.022 / U:2.588 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site