[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 3/3] x86/time: avoid reading the platform timer in rendezvous functions


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 20 Apr 2021 18:12:23 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FEjNOERNmXDf2fx6mSDICJTIjMjkKl1R61WjfFRsnTI=; b=Ox615dwtSq7LQdglASUaMCR43KZhNU+dNb600zpjst6KXIj3PAm3mUEEBz/D8mRd441ysCimhy+wmY5/UsrMb3nJva920LT1Jdahhx5tKfLK4FFG+5+t3+YeHpIuWeE+29dc14DERL7+ePR16hwTh1TUuzCWIgA0RoQNXXIh8kDTSvaHkDeF6ZuXDWNpgUD04APEqMDIoOopjY4iluuvBPX5j7TyqwbDjCcFwrhJCnbHbn8rZDEs/mKkTILZfNs8X+5BulOLj5u66SAhYNLXLlu5MSujersw9vkcBD+pQhj3ZSB0qK2x0XokKxuEgG2naTh/SSFNVIAr9n2IdwKx6g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BnjgcBk9IkeaP+3krFdNSFyiF+WgHRA12D2+YqcmTfCi3Ce26CTX8Aop23C0j6kga+ixEF62gtYvIAA0oJrwvCf5yJB24L2fKRW5q786NQytTHd/JxSv04mDCJ5EcPfWG73T181Eyjpl2e7kjky2rW7ZSvk3QiI2tGNfnCg6L+vRGgQCoWGIk65X4cFBksCudlnvXaSVIsCzIt+ar6ipcXHz1Yf65xPuzvu+SwW+qxmQ7Sq/lfivc604NYa49aZ6ynHicNKOzWHVRCDXToDhmrHenD6/ctdL3tWxOBay8hV2V3K6JMHvnfZtExMpeEyCqcfTv302h3SRBanzg62X/g==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 20 Apr 2021 16:12:42 +0000
  • Ironport-hdrordr: A9a23:ITrn3Kl2TDdxB0HD50dR9OkNB/3pDfO9j2dD5ilNYBxZY6Wkvu iUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLN/AZ6LZyOjnGezNolt4c/ZwzPmEzDj7eI178 tdWoBEIpnLAVB+5PyW3CCRD8sgzN6b8KqhmOfZyDNXQRt3brx7hj0ZNi+wOCRNNW57LLA+E4 eR4dcCijq7YHIMbtm6AH5tZZm4m/TgkpX6bRkaQyM28QXmt0LS1JfWMTi9mi0fXTRG3Ks4/Q H+/TDRy62/v5iAu33h/kDJ6ZA+oqqF9vJiA4i2htEROnHQjG+TFflccpmjmBxwn+218lYtl7 D30mYdFuB+8WnYcG3wgTaF4XiY7B8U53XvyUCVjBLYyKSTLlJKaLszuatjfhTU8EYmtt1nuZ g7p16xjJZLEQjG2B30+tmgbWAVqmOPvXEgneQP5kYvN7c2Vbk5l/16wGplVL0EHC789bk9Fv hvAMz29J9tACynRkGckW91zNO2WHMvWj+AX0gZo8SQlwNbhXZj0iIjtYEit0ZF0Kh4Z4hP5u zCPKgtvLZSTvUOZaY4IOsaW8O4BkHEXBqkChPfHX3XUIU8f17doZ/+57s4oMuwfoYT8Zc0kJ PdFHtFqG8bYSvVeIyz9awO1iqIbHS2XDzrxM0bzYN+oKfASL3iNjDGYEwykvGnv+4UDqTgKr iOEaMTJ8WmAXrlGI5P0QG7cYJVM2MiXMocvct+dEmJpu7NN432ps3WePveP9PWYHUZc1K6Jk FGcCn4Jc1G4EzucGT/mgLtV3TkfVG63Z8YKtmZw8EjjKw2cqFcuAkcjlq0ouuRLydZj6AwdE xiZJfukqaxo3iK7X/Fhl8ZfyZ1PwJw2vHNQnlKrQgFPwffarAYoeiSfmhUwT+hKgJgSdjVVC pSvU5+967yD5H4/1FsN/uXdkahy1cDrnODSJkR3oeZ493+R58+BpE6HIprFQvKEBRxsR1wqH hKbTIFQkO3LEKvtYyVyLgvQM3Pfdh1hwmmZeROr2jEiEmarcYzAkcAUyWWSs6RiwY2Tz9yjl l8mpVvxIaoqHKKEy8Ske44OFpDZCCyDKhdBAqIXolSh4vmYRp9V2uMmDychSwiY2aCzTRjuk XRaQmvPd3bCFtUvX5Vlpzn9155bU2xVUN9YHISi/w0KU32/lJIlcObbKu61GWcLmYYyuYGKT fffH85OQV13e260xaThRePHXgr3Y8VI+TYFbgvGoujnU+FGcmtr+UrDvVU9JFqOJTSqecNS/ uYYBLQAzXiCe8lsjbl0UoNCW1Rkj0Dnvzp0hG+szT98347HPbIIFNpA5scOMqR6mD4R/COlL V15OhFyNeYAyHUUJqhz6qSUhtobjX0ikSyR/szqZ9Vsbkp3YEDVqXzYH/t7jV/wB46LM3Ij0 sQT6Rw3aDZNuZUDr4vUhMc2mBsqc+GI0QquDHnG+MSfVkiiHnAItOCioC43YYHMwmkpAHqP0 OY/DAY1/DZXzGb3bpyMdN6HU1mLGw94m9l5uWMasn5DxirbfhK+B6fPmWmeLFQDIiDFrN4lG cx3/i428uWfTH/wgbeoH9SJb9P6X+uRYeKOz23cNQ4heCSCBCrmaul4Mm6kTfxR3+aUi0j9P F4XH1VSN9ChDkkhJAwyQ6oRMXM0wQYr2c=
  • Ironport-sdr: TP9xpw1GL6Q3whqpBvhXWURf5NRHVb+R+8Q2p6u1/x1Wu4BHXwd0Ye34GW2UEpRMDN6aKY+1sg 6oZNjHzvDknOioJK8myZmcabUeXv9811jLCxRlbpit0S1dhsM1b0fx61WNYDZVibLgTqTJlDCY TUAiJZq6Xqg4mD8FPdid3jMuB5xvVcA3QaXlPUe/BCTk6byev3iw09IFWGyl9Ge+oDBGDBD7IQ HU3SPr1KyrknLI7Yp+0OEEYShj6UcaIHugCvSOZxsqjrrRs9+K/Z7xmbOiglr8R8Dk0laj7q0j EWA=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Apr 01, 2021 at 11:55:10AM +0200, Jan Beulich wrote:
> Reading the platform timer isn't cheap, so we'd better avoid it when the
> resulting value is of no interest to anyone.
> 
> The consumer of master_stime, obtained by
> time_calibration_{std,tsc}_rendezvous() and propagated through
> this_cpu(cpu_calibration), is local_time_calibration(). With
> CONSTANT_TSC the latter function uses an early exit path, which doesn't
> explicitly use the field. While this_cpu(cpu_calibration) (including the
> master_stime field) gets propagated to this_cpu(cpu_time).stamp on that
> path, both structures' fields get consumed only by the !CONSTANT_TSC
> logic of the function.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v4: New.
> ---
> I realize there's some risk associated with potential new uses of the
> field down the road. What would people think about compiling time.c a
> 2nd time into a dummy object file, with a conditional enabled to force
> assuming CONSTANT_TSC, and with that conditional used to suppress
> presence of the field as well as all audited used of it (i.e. in
> particular that large part of local_time_calibration())? Unexpected new
> users of the field would then cause build time errors.

Wouldn't that add quite a lot of churn to the file itself in the form
of pre-processor conditionals?

Could we instead set master_stime to an invalid value that would make
the consumers explode somehow?

I know there might be new consumers, but those should be able to
figure whether the value is sane by looking at the existing ones.

Also, since this is only done on the BSP on the last iteration I
wonder if it really makes such a difference performance-wise to
warrant all this trouble.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.