Date: Wed, 09 Sep 2015 17:00:21 -0700 From: John Baldwin <john@baldwin.cx> To: freebsd-virtualization@freebsd.org Cc: Stefan Andritoiu <stefan.andritoiu@gmail.com> Subject: Re: Are the sched_choose() or tdq_choose() functions called after returning from an interrupt? Message-ID: <9328846.aE9oFjIUoK@ralph.baldwin.cx> In-Reply-To: <CAO3d8=YWAn%2B9FYUBhnTFee99e7NuZ1VoY9A%2BLn-zj=rDHboV%2BQ@mail.gmail.com> References: <CAO3d8=YWAn%2B9FYUBhnTFee99e7NuZ1VoY9A%2BLn-zj=rDHboV%2BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, June 12, 2015 10:51:20 AM 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)? The scheduler is always called to choose. An ithread may have awakened a more important thread than the originally interrupted thread. > More specifically, are the sched_choose() or tdq_choose() functions > called after returning from an IPI? As I said in my previous reply. This is not always true for IPIs. Device interrupt handlers that schedule an ithread will schedule the ithread and possibly preempt to it before returning from the interrupt. Only when the interrupted thread is resumed does it then fully cleanup the interrupted stack and execute iret. > Does an interrupt have it's own thread, or does it run in the context > of the interrupted thread as in Linux? Most device interrupts use a dedicated thread. Some device interrupt handlers do not. A driver can choose to register a non-threaded handler that runs on the stack of the interrupted thread. However, such handlers are limited in what they can do and must often defer work to other threads that they explicitly schedule (such as via a taskqueue). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9328846.aE9oFjIUoK>