From: Igor Mammedov <imammedo@redhat.com>
To: Zhao Liu <zhao1.liu@intel.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Peter Xu <peterx@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	mtosatti@redhat.com
Subject: Re: [PATCH v4 5/8] hpet: make main counter read lock-less
Date: Mon, 25 Aug 2025 17:10:09 +0200	[thread overview]
Message-ID: <20250825171009.0651153f@fedora> (raw)
In-Reply-To: <aKx5b7VH1p0NHxjL@intel.com>
On Mon, 25 Aug 2025 22:55:43 +0800
Zhao Liu <zhao1.liu@intel.com> wrote:
> On Thu, Aug 14, 2025 at 06:05:57PM +0200, Igor Mammedov wrote:
> > Date: Thu, 14 Aug 2025 18:05:57 +0200
> > From: Igor Mammedov <imammedo@redhat.com>
> > Subject: [PATCH v4 5/8] hpet: make main counter read lock-less
> > 
> > Make access to main HPET counter lock-less.
> > 
> > In unlikely event of an update in progress, readers will busy wait
> > untill update is finished.
> > 
> > As result micro benchmark of concurrent reading of HPET counter
> > with large number of vCPU shows over 80% better (less) latency.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > Reviewed-by: Peter Xu <peterx@redhat.com>
> > ---
> > v3:
> >   * make reader busy wait during update and reuse existing seqlock API
> >        Peter Xu <peterx@redhat.com>
> > ---
> >  hw/timer/hpet.c | 26 ++++++++++++++++++++------
> >  1 file changed, 20 insertions(+), 6 deletions(-)  
>  
> ...
> 
> > -    QEMU_LOCK_GUARD(&s->lock);
> >      if (addr == HPET_COUNTER) {
> > -        if (hpet_enabled(s)) {
> > -            cur_tick = hpet_get_ticks(s);
> > -        } else {
> > -            cur_tick = s->hpet_counter;
> > -        }
> > +        unsigned version;
> > +
> > +        /*
> > +         * Write update is rare, so busywait here is unlikely to happen
> > +         */
> > +        do {
> > +            version = seqlock_read_begin(&s->state_version);
> > +            if (unlikely(!hpet_enabled(s))) {  
> 
> is there any particular consideration for rearranging the order of the
> conditional branches here (and not directly using likely(hpet_enable()))?
not really, I suppose it should be the same either way.
> 
> > +                cur_tick = s->hpet_counter;
> > +            } else {
> > +                cur_tick = hpet_get_ticks(s);
> > +            }
> > +        } while (seqlock_read_retry(&s->state_version, version));
> >          trace_hpet_ram_read_reading_counter(addr & 4, cur_tick);
> >          return cur_tick >> shift;
> >      }  
> 
> Nice imprvoment!
> 
> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
> 
thanks!
next prev parent reply	other threads:[~2025-08-25 15:11 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-14 16:05 [PATCH v4 0/8] Reinvent BQL-free PIO/MMIO Igor Mammedov
2025-08-14 16:05 ` [PATCH v4 1/8] memory: reintroduce BQL-free fine-grained PIO/MMIO Igor Mammedov
2025-08-25 10:55   ` Philippe Mathieu-Daudé
2025-08-14 16:05 ` [PATCH v4 2/8] acpi: mark PMTIMER as unlocked Igor Mammedov
2025-08-14 16:05 ` [PATCH v4 3/8] hpet: switch to fain-grained device locking Igor Mammedov
2025-08-25 14:43   ` Zhao Liu
2025-08-14 16:05 ` [PATCH v4 4/8] hpet: move out main counter read into a separate block Igor Mammedov
2025-08-25 14:44   ` Zhao Liu
2025-08-14 16:05 ` [PATCH v4 5/8] hpet: make main counter read lock-less Igor Mammedov
2025-08-25 14:55   ` Zhao Liu
2025-08-25 15:10     ` Igor Mammedov [this message]
2025-08-14 16:05 ` [PATCH v4 6/8] add cpu_test_interrupt()/cpu_set_interrupt() helpers and use them tree wide Igor Mammedov
2025-08-14 19:05   ` Peter Xu
2025-08-20 15:01   ` Jason J. Herne
2025-08-21 15:57     ` Igor Mammedov
2025-08-21 15:56   ` [PATCH v5 " Igor Mammedov
2025-08-25  8:16     ` Harsh Prateek Bora
2025-08-25 15:06       ` Igor Mammedov
2025-08-25 10:35     ` Philippe Mathieu-Daudé
2025-08-25 15:02       ` Igor Mammedov
2025-08-25 15:28     ` Zhao Liu
2025-08-25 15:19       ` Igor Mammedov
2025-08-26  7:45         ` Zhao Liu
2025-08-26  8:47           ` Igor Mammedov
2025-08-26  9:27             ` Zhao Liu
2025-08-29  8:18             ` Paolo Bonzini
2025-08-29 12:33               ` Paolo Bonzini
2025-09-01 12:05                 ` Igor Mammedov
2025-09-01 12:06                   ` Paolo Bonzini
2025-08-14 16:05 ` [PATCH v4 7/8] kvm: i386: irqchip: take BQL only if there is an interrupt Igor Mammedov
2025-08-25 10:46   ` Philippe Mathieu-Daudé
2025-08-27  8:40     ` Igor Mammedov
2025-08-14 16:06 ` [PATCH v4 8/8] tcg: move interrupt caching and single step masking closer to user Igor Mammedov
2025-08-29  8:19 ` [PATCH v4 0/8] Reinvent BQL-free PIO/MMIO Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox
  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):
  git send-email \
    --in-reply-to=20250825171009.0651153f@fedora \
    --to=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=zhao1.liu@intel.com \
    /path/to/YOUR_REPLY
  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
  Be sure your reply has a Subject: header at the top and a blank line
  before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).