From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <44F5FB26.40700@domain.hid> Date: Wed, 30 Aug 2006 22:55:02 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Xenomai-core] Re: [patch, RFC] detect unhandled interrupts References: <44F49A6C.5050603@domain.hid> <44F592AD.2000900@domain.hid> <1156960547.4323.68.camel@domain.hid> <44F5DDF1.3030006@domain.hid> <1156970880.4323.74.camel@domain.hid> In-Reply-To: <1156970880.4323.74.camel@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2D56143F6D63449F25BBF719" Sender: jan.kiszka@domain.hid List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2D56143F6D63449F25BBF719 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Philippe Gerum wrote: > On Wed, 2006-08-30 at 20:50 +0200, Jan Kiszka wrote: >> Philippe Gerum wrote: >> >>> On Wed, 2006-08-30 at 15:29 +0200, Jan Kiszka wrote: >>> =20 >>>> Dmitry Adamushko wrote: >>>> =20 >>>>> On 29/08/06, Jan Kiszka wrote: >>>>> =20 >>>>>> Dmitry Adamushko wrote: >>>>>> >>>>>> I think the additional costs of maintaining an error counter are a= lmost >>>>>> negligible. The test is in the unlikely path, and the first condit= ion >>>>>> already keeps us away from touching the counter. >>>>>> =20 >>>>> But it's updated (unhandled =3D 0) any time the ISR(s) report somet= hing >>>>> different from XN_ISR_NONE. Hence, it's at the beginning of the xn= intr_t >>>>> structure, hopefully, at the same cache line with other highly-used= members >>>>> (i.e. isr, cookie and hits). >>>>> =20 >>>> Mmh, considering this and also the existing code I wonder if we coul= d >>>> optimise this a bit. I'm only looking at xnintr_irq_handler now (sha= ring >>>> is slow anyway): currently the intr object is touched both before >>>> (naturally...) and after the call to the ISR handler. Maybe we can p= ush >>>> all accesses before the handler for the fast path. E.g.: >>>> >>>> int unhandled =3D intr->unhandled; >>>> >>>> intr->unhandled =3D 0; >>>> ++intr->hits; >>>> s =3D intr->isr(...); >>>> >>>> if (s =3D=3D XN_ISR_NONE) { >>>> intr->unhandled =3D ++unhandled; >>>> if (unhandled =3D=3D XNINTR_MAX_UNHANDLED) >>>> ALARM! >>>> } >>>> >>>> =20 >>> Without speculating whether this could actually reduce cache misses o= r >>> not when the branch is taken, the main issue I see here is that we wo= uld >>> optimize the error case, at the expense of an additional memory fetch= ing >> No, it's the common path. Otherwise, I would have stopped already. I d= on't >> expect further memory access because the head of intr should be cached= >> already. >> >=20 > Sorry, my brain cells must be glued together, but then, I just don't ge= t > what your patch actually optimizes :o} Cache misses when accessing intr AFTER the ISR has finished (not on latest Pentium with 4 MB caches...) for the non-error case. --------------enig2D56143F6D63449F25BBF719 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFE9fsmniDOoMHTA+kRAmaPAJ9EOT+UAcnzj+53dzsETttZMdJRDQCfUnH9 Z1cPkiYGHPN4ORw4587okjU= =Ear5 -----END PGP SIGNATURE----- --------------enig2D56143F6D63449F25BBF719--