From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Xen on ARM IRQ latency and scheduler overhead Date: Sat, 18 Feb 2017 01:59:11 +0100 Message-ID: <1487379551.6732.117.camel@citrix.com> References: <1487356845.6732.100.camel@citrix.com> <69783c6d-1e65-3fa4-8b71-8c99d9e23eb6@arm.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0642137186820750902==" Return-path: In-Reply-To: <69783c6d-1e65-3fa4-8b71-8c99d9e23eb6@arm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Julien Grall , Stefano Stabellini , xen-devel@lists.xen.org Cc: george.dunlap@eu.citrix.com, edgar.iglesias@xilinx.com, nd@arm.com List-Id: xen-devel@lists.xenproject.org --===============0642137186820750902== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-HokLSrOFoyuhShCkUmj6" --=-HokLSrOFoyuhShCkUmj6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2017-02-17 at 19:44 +0000, Julien Grall wrote: > On 02/17/2017 06:40 PM, Dario Faggioli wrote: > > Does ARM > > have frequency scaling (I did remember something on xen-devel, but > > I am > > not sure whether it landed upstream)? >=20 > I guess you mean the series sent by globallogic ([1])? If so, it was=C2= =A0 > never upstreamed. >=20 Yep, that one. I was quite sure it did not went in, but was in hurry, and could not double check the code. Sorry. > However the frequency scaling may depend on the processor used and=C2=A0 > sometimes implemented using big.LITTLE (e.g the task has to switch). >=20 > I am not sure why it would matter in this case. >=20 It's hard to tell whether or not (and if yes, how much) it matter in this specific case. In general, when I was working on squeezing latency on bare-metal Linux, disabling scaling was one of the steps. It depends on quite a few different factors, but, roughly, during the time you're idle waiting for the interrupt, you're running at low frequency. When the interrupt comes, what happens depends on the governor, but you usually don't immediately jump to the highest frequency, because that happens gradually. And if all you do is something quick, in response to the timer interrupt (like in this and similar cases), you most likely end up doing that running at low frequency, which may impact latency (at least the latency of the completion of the work that the timer triggered). But I was also referring to the fact that the app is using some hardware counters, and a frequency value for updating them, and for converting their value to time. So I was wondering how the fact that frequency may be changing dynamically may interact with that (and that's because I'm pretty ignorant about ARM internals, I know :-/). Regards, Dario --=C2=A0 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-HokLSrOFoyuhShCkUmj6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYp5xfAAoJEBZCeImluHPuUhoP/j+4iN7tQm+nYqs6BWaBauPm r+EZK5WmzOLrRclTsTu2LP/BMSF+loIF3Ira7Kr6rMRHoDJpZaj6Uh8UNf/vG53j 9S38u4wws4x9dcfmUoM5SCYnBLsK7CYIPHUIlVCceYm9lHDGwwuPnXJwbfvj3gdo YGAyryMXhlX9NCqnd1W82Bsx8zGupGsERlPfng897EibmJ4c1dhrMDgthkF4v4B7 xj29aw+bgW0QVNQqFFzfG3VgZupIKP2J49NaN6QyflyEenzGhocEpvjDdrrIt4Tx jWPb2TSx0Xon6df+ZInf9qDz/DLcHQTOpnQerEdWhRelYh1XVO/Mst4x+TxHsNFj PbB/j9VA9AP5/qSVVU0etW8Ey2tBGbJ6NPc3YQ4VAnWvZywvntL4MGi8r6GLPT9u mGvn9cz8tx7ePYrSnPMPr+pgWkRoQT9LHykbvYQcG4cAKcw4eg2Vp1VAFNmfL6rY Y3rGtGtmckBxrTCAgLdT4YnPRTaN1pbql+4E/LpZZx6emIP/hWXULnHu3fwY+aU3 fHMCzfvv2aENDHXEouY7JTHUttRtI36xjTQQ58wMpcOhcRmEnXYaoQlKFX9fW7o9 AQEHY3RuNkwnQ9zXIczP23Gmh8EoZ/xDpuKvVMzJ3mV8FsPE84awMpVJD9+FW+gA Q5GekuEaZ/pIgATIVcLb =esYR -----END PGP SIGNATURE----- --=-HokLSrOFoyuhShCkUmj6-- --===============0642137186820750902== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0642137186820750902==--