Re: kernel: return from interrupt

From: Anurekh Saxena (anurekh_at_gmail.com)
Date: 11/11/04

  • Next message: Toxa: "usb dead on sony vaio" 
    Date: Thu, 11 Nov 2004 17:08:45 -0500
To: Robert Watson <rwatson@freebsd.org>

    > > I was under the impression that the 5.3 release had an option for full
    > > preemption. If I am correct, why does the kernel refuse to schedule on
    > > a return_from_interrupt if its not going back to userland? I can
    > > understand this being a problem if interrupts were nested, or return
    > > from a page fault in a critical section. Please correct me if I am
    > > wrong, but if a *high* priority interrupt thread is ready to run, it
    > > should be given a chance. Presuming the *interrupted* kernel path is
    > > going to give up the CPU fast enough is probably not a good idea.
    > >
    > > I hope I have sent this to the right mailing list.
    >
    > Even normal "options PREEMPTION" should do this. I know from tracing the
    > kernel in 6.x that that's the way the system behaves out of the box; with
    > PREEMPTION turned on in 5.x you should see the same behavior. One thing I
    > often do see, FWIW, is that if you're on an SMP box, the ithread will get
    > scheduled to run immediately on another CPU that's idle, so you won't
    > actually preempt the thread on the current CPU other than for the
    > interrupt handler. What behavior are you seeing that suggests this isn't
    > happening with PREEMPTION compiled in?

    I may be missing something fundamental here, but, doreti
    (exceptions.s) does not call 'ast' for an interrupted task, that does
    not have RPL of 3 (user). So, even if an interrupt is pending, and
    the 'NEEDRESCHED' is set, the scheduling decision is delayed till the
    kernel thread or whatever was running in the kernel sleeps, or give up
    the cpu(call mi_switch), or returns to user mode.

    AFAIK this is the only return path from an interrupt. Unless there is
    another return path for the interrupts, the scheduler is not invoked
    on a return.

    Thanks,
    -Anurekh

    > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    > robert@fledge.watson.org Principal Research Scientist, McAfee Research
    >
    >
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Toxa: "usb dead on sony vaio"

    Relevant Pages

    • RE: Maximum frequency of re-scheduling (minimum time quantum) que stio n
      ... >interrupt will also schedule if necessary. ... >>The catch here is, without the preemptable kernel option, the kernel ... Even with the option, it can't preempt ...
      (Linux-Kernel)
    • Re: What is the PREEMPTION option good for?
      ... I found another setup where PREEMPTION help -- nfs servers. ... give correct scheduling of interrupt threads, and that seems to be all ... FULL_PREEMPTION is apparently needed to get kernel threads preempted by ...
      (freebsd-arch)
    • Re: __wait_event_interruptible question
      ... > I got the next macro from sched.h from kernel 2.4.23_pre5. ... > from an interrupt service routine, I think it is possible that the ... lose the CPU before it calls schedule(). ... how it would work with preemption. ...
      (comp.os.linux.development.system)
    • Re: How linux schedules things when interrupts occur
      ... kernel deals with scheduling it's work. ... Suppose Linux is running on a single CPU system. ... When an APIC processed hardware interrupt comes and assuming the ... Then schedule is called and it will most likely schedule another process. ...
      (Linux-Kernel)
    • CONFIG_PREEMPT x86 assembly question
      ... Whily lazy-examining kernel code, I found the following interesting point. ... Why, after return from schedule(), first 0 is written to ... the idea of the preempt_count flag is to avoid ... causing nested interrupt while preempt_count flag is already reset. ...
      (Linux-Kernel)