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@xxxxxxxxxx>
> ---
> 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
