From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 6/6] xen: try to prevent idle timer from firing too often. Date: Wed, 6 Sep 2017 18:51:31 +0200 Message-ID: <1504716691.30217.12.camel@citrix.com> References: <150307710991.29525.3681195976643263117.stgit@Solace.fritz.box> <150307948527.29525.18126889783757078160.stgit@Solace.fritz.box> <6f69ea34-f510-71b5-7e54-b0f9cb5b0364@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5869757104702147904==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpdYH-0006H9-8H for xen-devel@lists.xenproject.org; Wed, 06 Sep 2017 16:51:45 +0000 In-Reply-To: <6f69ea34-f510-71b5-7e54-b0f9cb5b0364@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Wei Liu , George Dunlap , Andrew Cooper , Ian Jackson , Tim Deegan , Julien Grall , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============5869757104702147904== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-Q7FJ1Xj1T82o8cMtbEss" --=-Q7FJ1Xj1T82o8cMtbEss Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-08-29 at 17:30 +0100, George Dunlap wrote: > On 08/18/2017 07:04 PM, Dario Faggioli wrote: > >=20 > > What we're trying to avoid is one of those idle CPUs to > > wake up, only to discover that the grace period is still > > running, and that it hence could have be slept longer > > (saving more power). >=20 > So I think we're only taking about one or two extra wakeups per cpu > maximum -- if this even happens at all. >=20 Yep, indeed. > Wouldn't it be better to first add a performance counter, and check > to > see if and how often this situation happens? >=20 The counter is there already. It's rcu_idle_timer ("RCU: idle_timer"). > > This patch implements an heuristic aimed at achieving > > that, at the price of having to call cpumask_weight() on > > the 'entering idle' path, on CPUs with queued callbacks. >=20 > The heuristic seems a bit strange to me too: why would each cpu > increase > the grace period in a linear fashion?=C2=A0=C2=A0I haven't looked at the = grace > period code, but I would have expected each one to be independent; > and > so there'd be a "diminishing returns" effect when adding more cpus. >=20 I like the idea, in general. Let me just double check whether I'm understanding what you're suggesting properly. First of all, what do you mean with "adding more cpus"? Adding to what? The timer is useful when a CPU, which is participating in the grace period, goes idle, while the grace period is not finished. From that point on, the number of CPUs participating to _that_ grace period will monotonically decrease, until it reaches zero. So what does 'adding' means in this context? > If we have to have something like this (which I'm not at all > convinced > we do), I would think having a single number which self-adjusted so > that > the number of 'misses' was around 1% would be a good balance.=C2=A0=C2=A0= What > about a heuristic like this: >=20 > 1. If the timer goes off and the grace period isn't over, add 10ms to > the timer period > 2. If the timer goes off and the grace period *is* over, subtract > 100us > from the timer period >=20 So, let's say we start with a period of 1ms. First time RCU is used, the timer fires twice: the first time it finds the grace period is still ongoning --and hence the period becomes 11ms-- while the seconds finds it over --so the period is now 10.9ms. Next time RCU is used, if the timer is necessary, we use 10.9ms. Am I getting your proposal right? If yes, do we allow the period to become smaller than the initial value (1ms, in the example above). I'd say we better not (or that we at least set a lower bound), or, given enough occurrences of cases when the timer fires and finds the grace period to be over in a row, the period can become 0! Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Q7FJ1Xj1T82o8cMtbEss 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 iQIbBAABCAAGBQJZsCeUAAoJEBZCeImluHPuo7oP+NGWPSs3bVIXIp7kDNkcghYG YRfD9kCLGBtSB91BLV0VXVRjjJyT7E4zMMisilk7x3yG1XnySL8z2ZVsAc/ZWeco EHBm5030fwRNNR3rhoj5Cbf1zUpqI7nG60DnTF8z2Bzo8j0seq0DaYKegFDR7jod P94k435q71o2f0WcN/m6mTAC8VxySt3Awyj6aJl2fUNZmeBOXJiN30CW4E3QwdZT hc9mVCH8BlqlN/pqBeFh6rQG9wI+W/MFnQKpRmFjB99+r0yTtkf4JQmZKROs9PSd rUh+tEZ6n8IxzJLBU5xRiTrSnIQnwWUmsI62mpkxV5YEn+87Tz4L9/NFKsNYOqhI xbqRLkdItiJXsPz42CT02xPnW1MTgUmeG2Ez+m9wfoRC0dQSz5YihrVIGvclxMX/ /nQTDOngxcpfMe01oj2KQaPJ/IU9HVdN2vBFhCvBKeij0zUE3IEf9cDgtrYyv813 j+tNzNz7Iy0Qxw4XUP+3L2PPPlef/+InVYCgikY/VDzm9aX44rlrqIzdRoJOvP8E NpQnNTMtiv04edJXLryl3UfOL0DFR/pRJTCRa0ez9qBQtVv0LbpT1bT++uhpss9s QB3lC9pQX3nRSOZ1hp6BiXtV1XyZvvRzPMJcIDgtgObu2kO2csUBOL57STLi0PhG Feiw+8tB0Q9M5SjU504= =Jn91 -----END PGP SIGNATURE----- --=-Q7FJ1Xj1T82o8cMtbEss-- --===============5869757104702147904== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5869757104702147904==--