Date: Fri, 12 Jun 2015 23:04:26 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Stefan Andritoiu <stefan.andritoiu@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Are the sched_choose() or tdq_choose() functions called after returning from an interrupt? Message-ID: <20150612200426.GG2080@kib.kiev.ua> In-Reply-To: <CAO3d8=Zq%2BPma2NRUimPN_Hj0B1Ys6Dpd%2BEgx-og8z5f7A3fk6A@mail.gmail.com> References: <CAO3d8=Zq%2BPma2NRUimPN_Hj0B1Ys6Dpd%2BEgx-og8z5f7A3fk6A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 12, 2015 at 10:50:11AM +0300, Stefan Andritoiu wrote: > Hello, > > When returning from an interrupt, does it switch directly the thread > that was interrupted? Or is the scheduler called to choose a thread to > run (most probable the thread that was interrupted)? > > More specifically, are the sched_choose() or tdq_choose() functions > called after returning from an IPI? I do not quite understand why do you use the term IPI there, but it does not matter; both device interrupts and IPI cause similar > > Does an interrupt have it's own thread, or does it run in the context > of the interrupted thread as in Linux? Both, it is up to the interrupt code author to select model. Either you use fast interrupt filter, or thread, for interrupt handling code. Look at e.g. the lapic_handle_timer(), which is called from the assembler trampoline when LAPIC timer interrupt is generated. The code calls critical_enter()/critical_exit() pair, and critical_exit() checks the td_owepreempt member of the curthread to see if anything before or during processing of the timer tick interrupt (including the scheduler) tickled the preemption. If yes, mi_switch() is called to cause the context switch on the processor. Hardware interrupts result in the call to intr_event_handle(). There you can see the FILTER/THREAD cases. The FILTER is executed in whatever context that was active during the interrupt delivery, which of course causes severe restrictions on the things that can be used or accessed in the handler. THREAD handler results in the interrupt thread put on the run queue. Since the priority of the interrupt threads is very high, it should be put on CPU 'soon', in the critical_exit() in the intr_event_handle() (look only for the !INTR_FILTER variant of the function, INTR_FILTER is buggy).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150612200426.GG2080>