All of lore.kernel.org
 help / color / mirror / Atom feed
From: dingtianhong@huawei.com (Ding Tianhong)
To: linux-arm-kernel@lists.infradead.org
Subject: Problem about CPU stalling in hrtimer_intterrupts()
Date: Thu, 22 Oct 2015 17:28:56 +0800	[thread overview]
Message-ID: <5628AC58.2030509@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1510220942010.4012@nanos>

On 2015/10/22 15:43, Thomas Gleixner wrote:
> On Thu, 22 Oct 2015, Yang Yingliang wrote:
>> I use the kernel-4.1.6 running on arm64.
>> My testcase is that it calls clock_settime and clock_adjtime alternately with
>> random params on each core. My system has 32 cores.
>>
>> I found the cpu stalling in  hrtimer_intterrupts(). So I added some debug info
>> in hrtimer_intterrupts() and found that the while loop runs 1020437660 times
>> and takes 98761 jiffies(HZ=250).
>>
>> Some debug log is here:
>> ---start---
>> Jan 01 00:03:32 Linux kernel: i:0 basenow.tv64:4809284991830
>> hrtimer_get_softexpires_tv64(timer):4440120000000 ccpu0
>> timer:ffffffdffdec6138, timer->function:ffffffc000129b84
>> Jan 01 00:03:32 Linux kernel: i:0 basenow.tv64:4809284991830
>> hrtimer_get_softexpires_tv64(timer):4440120000000 ccpu0
> 
> Something is rearming a timer over and over with expiry time in the
> past.
> 
> Thanks,
> 
> 	tglx
> 


Hi Thomas:

This problem could only occur on the system with 32 cores, when I cut the cores to 16, this problem disappeared, 
so I think there is some parallel problem when the 32 core set clock time together:

I try to reproduce the scene:

1.do_settimeofday64
2.update tk time
3.update base time offset
4.update expires_next

the 3 and 4 will be called in softirq, but the hrtimer_interrupt may break the order and run before 3, I am not
sure whether this could make the problem, do we need to update base time and expires_next in the hrtimer_interrupt?
maybe I miss something, thanks for any suggestion.

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 93ef7190..9adab23 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1254,6 +1254,7 @@ void hrtimer_interrupt(struct clock_event_device *dev)

raw_spin_lock(&cpu_base->lock);
entry_time = now = hrtimer_update_base(cpu_base);
+ hrtimer_force_reprogram(cpu_base, 0);
retry:
cpu_base->in_hrtirq = 1;


Thanks

Ding


> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Ding Tianhong <dingtianhong@huawei.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Yang Yingliang <yangyingliang@huawei.com>
Cc: <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	Hanjun Guo <hanjun.guo@linaro.org>
Subject: Re: Problem about CPU stalling in hrtimer_intterrupts()
Date: Thu, 22 Oct 2015 17:28:56 +0800	[thread overview]
Message-ID: <5628AC58.2030509@huawei.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1510220942010.4012@nanos>

On 2015/10/22 15:43, Thomas Gleixner wrote:
> On Thu, 22 Oct 2015, Yang Yingliang wrote:
>> I use the kernel-4.1.6 running on arm64.
>> My testcase is that it calls clock_settime and clock_adjtime alternately with
>> random params on each core. My system has 32 cores.
>>
>> I found the cpu stalling in  hrtimer_intterrupts(). So I added some debug info
>> in hrtimer_intterrupts() and found that the while loop runs 1020437660 times
>> and takes 98761 jiffies(HZ=250).
>>
>> Some debug log is here:
>> ---start---
>> Jan 01 00:03:32 Linux kernel: i:0 basenow.tv64:4809284991830
>> hrtimer_get_softexpires_tv64(timer):4440120000000 ccpu0
>> timer:ffffffdffdec6138, timer->function:ffffffc000129b84
>> Jan 01 00:03:32 Linux kernel: i:0 basenow.tv64:4809284991830
>> hrtimer_get_softexpires_tv64(timer):4440120000000 ccpu0
> 
> Something is rearming a timer over and over with expiry time in the
> past.
> 
> Thanks,
> 
> 	tglx
> 


Hi Thomas:

This problem could only occur on the system with 32 cores, when I cut the cores to 16, this problem disappeared, 
so I think there is some parallel problem when the 32 core set clock time together:

I try to reproduce the scene:

1.do_settimeofday64
2.update tk time
3.update base time offset
4.update expires_next

the 3 and 4 will be called in softirq, but the hrtimer_interrupt may break the order and run before 3, I am not
sure whether this could make the problem, do we need to update base time and expires_next in the hrtimer_interrupt?
maybe I miss something, thanks for any suggestion.

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 93ef7190..9adab23 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1254,6 +1254,7 @@ void hrtimer_interrupt(struct clock_event_device *dev)

raw_spin_lock(&cpu_base->lock);
entry_time = now = hrtimer_update_base(cpu_base);
+ hrtimer_force_reprogram(cpu_base, 0);
retry:
cpu_base->in_hrtirq = 1;


Thanks

Ding


> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 



  reply	other threads:[~2015-10-22  9:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-22  6:43 Problem about CPU stalling in hrtimer_intterrupts() Yang Yingliang
2015-10-22  6:43 ` Yang Yingliang
2015-10-22  7:43 ` Thomas Gleixner
2015-10-22  7:43   ` Thomas Gleixner
2015-10-22  9:28   ` Ding Tianhong [this message]
2015-10-22  9:28     ` Ding Tianhong
2015-10-22 10:25     ` Thomas Gleixner
2015-10-22 10:25       ` Thomas Gleixner
2015-10-22 13:43       ` Yang Yingliang
2015-10-22 13:43         ` Yang Yingliang
2015-10-24  9:58         ` Thomas Gleixner
2015-10-24  9:58           ` Thomas Gleixner

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=5628AC58.2030509@huawei.com \
    --to=dingtianhong@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.