Date: Mon, 27 May 2013 09:34:32 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Orit Moskovich <oritm@mellanox.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: preemptive kernel Message-ID: <20130527063432.GY3047@kib.kiev.ua> In-Reply-To: <981733489AB3BD4DB24B48340F53E0A55B0D56E0@MTLDAG01.mtl.com> References: <981733489AB3BD4DB24B48340F53E0A55B0D5590@MTLDAG01.mtl.com> <20130526154752.GT3047@kib.kiev.ua> <981733489AB3BD4DB24B48340F53E0A55B0D56E0@MTLDAG01.mtl.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130527063432.GY3047>