public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <zhexu@redhat.com>
To: Peter Xu <zhexu@redhat.com>
Cc: kvm@vger.kernel.org, "Marcelo Tosatti" <mtosatti@redhat.com>,
	"Luiz Capitulino" <lcapitulino@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [kvm-unit-tests PATCH] tscdeadline_latency: Check condition first before loop
Date: Thu, 11 Jul 2019 15:33:35 +0800	[thread overview]
Message-ID: <20190711073335.GC7847@xz-x1> (raw)
In-Reply-To: <20190711071756.2784-1-peterx@redhat.com>

On Thu, Jul 11, 2019 at 03:17:56PM +0800, Peter Xu wrote:
> This patch fixes a tscdeadline_latency hang when specifying a very
> small breakmax value.  It's easily reproduced on my host with
> parameters like "200000 10000 10" (set breakmax to 10 TSC clocks).
> 
> The problem is test_tsc_deadline_timer() can be very slow because
> we've got printf() in there.  So when reach the main loop we might
> have already triggered the IRQ handler for multiple times and we might
> have triggered the hitmax condition which will turn IRQ off.  Then
> with no IRQ that first HLT instruction can last forever.
> 
> Fix this by simply checking the condition first in the loop.
> 
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  x86/tscdeadline_latency.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/x86/tscdeadline_latency.c b/x86/tscdeadline_latency.c
> index 0617a1b..4ee5917 100644
> --- a/x86/tscdeadline_latency.c
> +++ b/x86/tscdeadline_latency.c
> @@ -118,9 +118,9 @@ int main(int argc, char **argv)
>      test_tsc_deadline_timer();
>      irq_enable();
>  
> -    do {
> +    /* The condition might have triggered already, so check before HLT. */
> +    while (!hitmax && table_idx < size)

Hmm... I think this is not ideal too in that variables (e.g., hitmax)
could logically still change between the condition check and HLT below
(though this patch already runs nicely here).  Maybe we can simply use
"nop" or "pause" instead of "hlt".

I tested that using pause fixes the problem too.

>          asm volatile("hlt");
> -    } while (!hitmax && table_idx < size);
>  
>      for (i = 0; i < table_idx; i++) {
>          if (hitmax && i == table_idx-1)
> -- 
> 2.21.0
> 

Regards,

-- 
Peter Xu

  reply	other threads:[~2019-07-11  7:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-11  7:17 [kvm-unit-tests PATCH] tscdeadline_latency: Check condition first before loop Peter Xu
2019-07-11  7:33 ` Peter Xu [this message]
2019-07-11 14:05   ` Sean Christopherson
2019-07-11 23:27     ` Peter Xu
2019-07-11 23:34       ` Sean Christopherson

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=20190711073335.GC7847@xz-x1 \
    --to=zhexu@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lcapitulino@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.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