From owner-freebsd-hackers@FreeBSD.ORG Mon May 27 06:34:38 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9B106CE6 for ; Mon, 27 May 2013 06:34:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id EA42C65E for ; Mon, 27 May 2013 06:34:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r4R6YYL4063806; Mon, 27 May 2013 09:34:34 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r4R6YYL4063806 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r4R6YW6L063805; Mon, 27 May 2013 09:34:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 May 2013 09:34:32 +0300 From: Konstantin Belousov To: Orit Moskovich Subject: Re: preemptive kernel Message-ID: <20130527063432.GY3047@kib.kiev.ua> References: <981733489AB3BD4DB24B48340F53E0A55B0D5590@MTLDAG01.mtl.com> <20130526154752.GT3047@kib.kiev.ua> <981733489AB3BD4DB24B48340F53E0A55B0D56E0@MTLDAG01.mtl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JoKCChanR9DHu5K+" Content-Disposition: inline In-Reply-To: <981733489AB3BD4DB24B48340F53E0A55B0D56E0@MTLDAG01.mtl.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 06:34:38 -0000 --JoKCChanR9DHu5K+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 27, 2013 at 05:00:13AM +0000, Orit Moskovich wrote: > Just to be more specific - On x86, during a filter routine all interrupts= are disabled on the cpu currently handling a filter routine or only interr= upts on the IRQ that generated the interrupt?=20 The CPU enters the handler through the interrupt gate, which clears the PSL_I. Interrupts are not re-enabled until the handler return. > Is it possible that on a different cpu an interrupt (filter or ithread) o= f the same IRQ will run? Should worry about locking data because an ithread= can preempt the same ithread or they'll run concurrently on different cpus? The APIC or PCI MSI registers are programmed in the physical destination mode. This, together with the fact that interrupts are disabled on the target CPU, prevents parallel or nested execution of the filter. Having both filter and ithread for the same interrupt is apparently possible but weird. I do not see anything which would prevent interrupt filter =66rom being executed while the ithread is running. But again, this is very unusual setup. ithread has single stack, it cannot be run simultaneously on several CPUs. >=20 > -----Original Message----- > From: Konstantin Belousov [mailto:kostikbel@gmail.com]=20 > Sent: Sunday, May 26, 2013 06:48 PM > To: Orit Moskovich > Cc: freebsd-hackers@freebsd.org > Subject: Re: preemptive kernel >=20 > On Sun, May 26, 2013 at 11:09:03AM +0000, Orit Moskovich wrote: > > Can a filter routine preempt another filter routine? And can an interru= pt thread (or a filter routine) preempt another ithread? >=20 > Filter handler borrows the context from the thread executed at the time o= f the interrupt. At least on x86 (i.e. i386 and amd64) interrupt handlers = are executed with the interrupts disabled. So the filter cannot interrupt = another filter. >=20 > Interrupt threads are executed with the interrupts enabled. So if an inte= rrupt is delivered to the CPU while the CPU executed the ithread, the filte= r 'preempts' the ithread by executing in its context. For the same reason,= if the interrupt delivered causes a higher-priority thread become ready to= run, then the new runnable thread could preempt the interrupt thread accor= ding to the priority, affinity and other factors considered by a scheduler. --JoKCChanR9DHu5K+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJRov53AAoJEJDCuSvBvK1BElQP/3cEU/CRzJ9dKzNP7N5j87vX aMM8+sSNBrQPwtYKt46ruQspHvkkZwhSJSIeih7PJtOYAmjhHPPiqwTDzLulD8tQ baEOzZEQJrSZGwk5g14LC5J2hjr4B8KxV7s1ZN/Cso2N1b7N28aTyGmOW8dcbMTz k57MV1zeXe7aZVVZWOEVh4A1N7DsbWT6pzUgbzGZQ1bBkxZzF8LxVgcI03wG/Zg9 DmnCWgp93beC4qWf13PizA7Asw6X0xOA9i30V5tsfp6WDfTGrdhu++YSDpPuVk1B j7PA7XdJP1l8oce5EpOIX9bvmt8cZbH0ro2H6AJx5A5JFFOa5gdkYrhJCyUzemZy 96lfHmiicYNeLFd8Ky/H9xtc0YJA0bbj/3+kakTeHzeNpGaq1hi5H1e9Xl30vGoL 4UAJYfHy2YTng/10M3vbH0NtY2lXfxqvf4gcvvepKH1OBjGJOifqZ9SEoAw+yZhm eSukpLM5Tx+eIhC0UB1tP5U3Kkk16gIo6yUUnDKUBP05cktBad4BGgldfO/MJn2z 5l8v8tfsfkX00Z7GsdK87RNnBpk0ThZhPBdgsWEksC7x9IihP/5Z3Aj5Pr2hWDvD wZi2qZJjhIt7Iw9wf3NUL3n1GMONYy89akluqEYukffE+X2wL5W4kY7JIBOKgHGx hYnTOdnkg1xu5fOMxoWo =ZfNo -----END PGP SIGNATURE----- --JoKCChanR9DHu5K+--