This series contains few patches resulting from the notes I
took while reviewing Mark ADB series last Sunday, in particular:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg712078.html

I have another patch for hw/input/hid.c but I prefer to hold it
to test it more.

Philippe Mathieu-Daudé (7):
  qemu-common: Briefly document qemu_timedate_diff() unit
  block/qcow2: Document cache_clean_interval field holds seconds
  block/curl: Reduce timer precision to milli-second
  hw/virtio/virtio-balloon: Rename timer field including 'ms' unit
  hw/rtc/m48t59: Reduce timer precision to milli-second
  hw/ipmi/ipmi_bmc_extern: Reduce timer precision to milli-second
  hw/watchdog/wdt_aspeed: Reduce timer precision to micro-second

 block/qcow2.h                      |  1 +
 hw/rtc/m48t59-internal.h           |  2 +-
 include/hw/virtio/virtio-balloon.h |  2 +-
 include/hw/watchdog/wdt_aspeed.h   |  2 +-
 include/qemu-common.h              |  1 +
 block/curl.c                       | 15 +++++++--------
 hw/ipmi/ipmi_bmc_extern.c          | 19 +++++++++---------
 hw/rtc/m48t59.c                    | 31 +++++++++++++++---------------
 hw/virtio/virtio-balloon.c         | 14 ++++++++------
 hw/watchdog/wdt_aspeed.c           | 24 ++++++++++++-----------
 softmmu/vl.c                       |  2 +-
 11 files changed, 60 insertions(+), 53 deletions(-)

-- 
2.21.3

On 6/16/20 12:51 AM, Philippe Mathieu-Daudé wrote:
> This series contains few patches resulting from the notes I
> took while reviewing Mark ADB series last Sunday, in particular:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg712078.html
> 
> I have another patch for hw/input/hid.c but I prefer to hold it
> to test it more.

How does this reduce pressure?  The resolution of the timer doesn't seem to be
affected by these patches, only the precision of the inputs.

It seems like standardizing on nanoseconds makes some things easier, and allows
the resolution of the implementation to vary to a much larger degree.


r~

On 16/06/20 09:51, Philippe Mathieu-Daudé wrote:
> This series contains few patches resulting from the notes I
> took while reviewing Mark ADB series last Sunday, in particular:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg712078.html
> 
> I have another patch for hw/input/hid.c but I prefer to hold it
> to test it more.

This is in principle a very good idea; however, util/qemu-timer.c does
not use the scale to coalesce low-precision timers with nearby
high-precision ones.

Paolo

On 6/18/20 2:23 PM, Paolo Bonzini wrote:
> On 16/06/20 09:51, Philippe Mathieu-Daudé wrote:
>> This series contains few patches resulting from the notes I
>> took while reviewing Mark ADB series last Sunday, in particular:
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg712078.html
>>
>> I have another patch for hw/input/hid.c but I prefer to hold it
>> to test it more.
> 
> This is in principle a very good idea; however, util/qemu-timer.c does
> not use the scale to coalesce low-precision timers with nearby
> high-precision ones.

IOW this doesn't reduce the pressure, but simply makes the code easier?
Only the cover mentions 'pressure', so maybe the patches can still be
reviewed/queued in their current state?

On 18/06/20 14:26, Philippe Mathieu-Daudé wrote:
>> This is in principle a very good idea; however, util/qemu-timer.c does
>> not use the scale to coalesce low-precision timers with nearby
>> high-precision ones.
> IOW this doesn't reduce the pressure, but simply makes the code easier?

Easier, or harder depending on the point of view.  The reason why scale
exists is just because QEMU_CLOCK_REALTIME used to be millisecond based;
having to scale based on the clock was really ugly code, and furthermore
the scale provides an easy way to switch timers from one clock to
another without having to modify every deadline computation.

One might argue that the scale adds to QEMU's cognitive weight for
little benefit.  You might counter-argue that having to scale up to
nanoseconds every time is a pain in the ass, and I am not sure which
side I actually agree with.

> Only the cover mentions 'pressure', so maybe the patches can still be
> reviewed/queued in their current state?

Yes, of course.

Paolo