From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 20:04:36 2015 Return-Path: Delivered-To: freebsd-hackers@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6065E244 for ; Fri, 12 Jun 2015 20:04:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8C22796 for ; Fri, 12 Jun 2015 20:04:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5CK4RFN053904 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 12 Jun 2015 23:04:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5CK4RFN053904 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5CK4QQX053844; Fri, 12 Jun 2015 23:04:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Jun 2015 23:04:26 +0300 From: Konstantin Belousov To: Stefan Andritoiu 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> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:04:36 -0000 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).