From: Mason <slash.tmp@free.fr> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Viresh Kumar <viresh.kumar@linaro.org>, Daniel Lezcano <daniel.lezcano@linaro.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Mans Rullgard <mans@mansr.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux PM <linux-pm@vger.kernel.org>, cpufreq <cpufreq@vger.kernel.org> Subject: Re: schedule_timeout sleeps too long after dividing CPU frequency Date: Fri, 15 May 2015 14:45:28 +0200 [thread overview] Message-ID: <5555EA68.7030006@free.fr> (raw) In-Reply-To: <20150515115852.GJ2067@n2100.arm.linux.org.uk> On 15/05/2015 13:58, Russell King - ARM Linux wrote: > On Fri, May 15, 2015 at 12:36:10PM +0200, Mason wrote: >> On 15/05/2015 11:51, Russell King - ARM Linux wrote: >> >>> As you don't say which kernel version you're using, >> >> Sorry about that, I thought the patch-generating command >> I posted conveyed the information. >> >> $ git diff v3.14.41 HEAD >tango.patch && xz tango.patch >> >> I'm using the 3.14.y branch from linux-stable. > > So you're using a kernel over a year old... The sad part is: I'm working on the "new" kernel. The current "official" kernel is 3.4 (and I'm afraid there's a 2.6.32 still kicking around somewhere). I'm trying to convince management that one of the advantages of mainlining the port is that it is easier to switch to newer kernels. Do you agree with this assertion? >>> for all we know, you might be using a version which omits some fixes >>> in this area, such as this one which you really must have if your >>> timer is operating in period mode: >>> >>> fe79a9ba1196 clockevents: Adjust timer interval when frequency changes >> >> Hmmm, according to git log, this patch was accepted during >> the 3.14-rc2 merge window. Why didn't it make it for 3.14? > > No it wasn't: > > $ git describe --contains fe79a9ba1196 > v3.15-rc1~123^2~12 > > It was merged during the merge window immediately preceding v3.15-rc1. > >> By any chance, is there a patch that would allow the platform >> to get high-resolution timers when using smp_twd? > > I think you'll have to do the research for that yourself... what > I can say is that TWD is capable of one-shot mode, Is one-shot mode preferred over periodic mode? (Seems counter-intuitive, as one-shot mode needs to be periodically reprogrammed, whereas periodic mode just keeps firing.) > and is capable of running as a high-res timer: > > Per CPU device: 0 > Clock Event Device: local_timer > max_delta_ns: 21691754031 > min_delta_ns: 1000 > mult: 425201762 > shift: 31 > mode: 3 <== CLOCK_EVT_MODE_ONESHOT > next_event: 595603944000000 nsecs > set_next_event: twd_set_next_event > set_mode: twd_set_mode > event_handler: hrtimer_interrupt <== indicates that it's switched > to high-res mode > retries: 0 I'm confused. In the "High-resolution timers not supported when using smp_twd on Cortex A9" thread, you seemed to agree that TWD could not be used as a hrtimer... > Yes - because the TWD stops in low power modes, which makes it > unsuitable as a high-resolution timer. These kinds of issues > are annoying, but it's the way things are. So it looks like TWD can be used as a hrtimer, but something on my platform is making it choose otherwise, and it is not the CLOCK_EVT_FEAT_C3STOP flag? Regards.
WARNING: multiple messages have this Message-ID (diff)
From: slash.tmp@free.fr (Mason) To: linux-arm-kernel@lists.infradead.org Subject: schedule_timeout sleeps too long after dividing CPU frequency Date: Fri, 15 May 2015 14:45:28 +0200 [thread overview] Message-ID: <5555EA68.7030006@free.fr> (raw) In-Reply-To: <20150515115852.GJ2067@n2100.arm.linux.org.uk> On 15/05/2015 13:58, Russell King - ARM Linux wrote: > On Fri, May 15, 2015 at 12:36:10PM +0200, Mason wrote: >> On 15/05/2015 11:51, Russell King - ARM Linux wrote: >> >>> As you don't say which kernel version you're using, >> >> Sorry about that, I thought the patch-generating command >> I posted conveyed the information. >> >> $ git diff v3.14.41 HEAD >tango.patch && xz tango.patch >> >> I'm using the 3.14.y branch from linux-stable. > > So you're using a kernel over a year old... The sad part is: I'm working on the "new" kernel. The current "official" kernel is 3.4 (and I'm afraid there's a 2.6.32 still kicking around somewhere). I'm trying to convince management that one of the advantages of mainlining the port is that it is easier to switch to newer kernels. Do you agree with this assertion? >>> for all we know, you might be using a version which omits some fixes >>> in this area, such as this one which you really must have if your >>> timer is operating in period mode: >>> >>> fe79a9ba1196 clockevents: Adjust timer interval when frequency changes >> >> Hmmm, according to git log, this patch was accepted during >> the 3.14-rc2 merge window. Why didn't it make it for 3.14? > > No it wasn't: > > $ git describe --contains fe79a9ba1196 > v3.15-rc1~123^2~12 > > It was merged during the merge window immediately preceding v3.15-rc1. > >> By any chance, is there a patch that would allow the platform >> to get high-resolution timers when using smp_twd? > > I think you'll have to do the research for that yourself... what > I can say is that TWD is capable of one-shot mode, Is one-shot mode preferred over periodic mode? (Seems counter-intuitive, as one-shot mode needs to be periodically reprogrammed, whereas periodic mode just keeps firing.) > and is capable of running as a high-res timer: > > Per CPU device: 0 > Clock Event Device: local_timer > max_delta_ns: 21691754031 > min_delta_ns: 1000 > mult: 425201762 > shift: 31 > mode: 3 <== CLOCK_EVT_MODE_ONESHOT > next_event: 595603944000000 nsecs > set_next_event: twd_set_next_event > set_mode: twd_set_mode > event_handler: hrtimer_interrupt <== indicates that it's switched > to high-res mode > retries: 0 I'm confused. In the "High-resolution timers not supported when using smp_twd on Cortex A9" thread, you seemed to agree that TWD could not be used as a hrtimer... > Yes - because the TWD stops in low power modes, which makes it > unsuitable as a high-resolution timer. These kinds of issues > are annoying, but it's the way things are. So it looks like TWD can be used as a hrtimer, but something on my platform is making it choose otherwise, and it is not the CLOCK_EVT_FEAT_C3STOP flag? Regards.
next prev parent reply other threads:[~2015-05-15 12:45 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-12 14:32 schedule_timeout sleeps too long after dividing CPU frequency Mason 2015-05-12 14:32 ` Mason 2015-05-12 14:46 ` Viresh Kumar 2015-05-12 14:46 ` Viresh Kumar 2015-05-12 15:14 ` Mason 2015-05-12 15:14 ` Mason 2015-05-12 15:50 ` Russell King - ARM Linux 2015-05-12 15:50 ` Russell King - ARM Linux 2015-05-12 16:14 ` Mason 2015-05-12 16:14 ` Mason 2015-05-13 16:51 ` Mason 2015-05-13 16:51 ` Mason 2015-05-14 2:13 ` Viresh Kumar 2015-05-14 2:13 ` Viresh Kumar 2015-05-14 11:22 ` Mason 2015-05-14 11:22 ` Mason 2015-05-14 11:54 ` Viresh Kumar 2015-05-14 11:54 ` Viresh Kumar 2015-05-14 13:06 ` Mason 2015-05-14 13:06 ` Mason 2015-05-14 13:53 ` Russell King - ARM Linux 2015-05-14 13:53 ` Russell King - ARM Linux 2015-05-14 14:51 ` Mason 2015-05-14 14:51 ` Mason 2015-05-14 13:59 ` Viresh Kumar 2015-05-14 13:59 ` Viresh Kumar 2015-05-14 13:59 ` Viresh Kumar 2015-05-14 14:38 ` Viresh Kumar 2015-05-14 14:38 ` Viresh Kumar 2015-05-14 14:42 ` Russell King - ARM Linux 2015-05-14 14:42 ` Russell King - ARM Linux 2015-05-15 9:29 ` Mason 2015-05-15 9:29 ` Mason 2015-05-15 9:51 ` Russell King - ARM Linux 2015-05-15 9:51 ` Russell King - ARM Linux 2015-05-15 10:01 ` Viresh Kumar 2015-05-15 10:01 ` Viresh Kumar 2015-05-15 10:36 ` Mason 2015-05-15 10:36 ` Mason 2015-05-15 11:58 ` Russell King - ARM Linux 2015-05-15 11:58 ` Russell King - ARM Linux 2015-05-15 12:45 ` Mason [this message] 2015-05-15 12:45 ` Mason 2015-05-15 13:15 ` Russell King - ARM Linux 2015-05-15 13:15 ` Russell King - ARM Linux 2015-05-15 13:58 ` Mason 2015-05-15 18:35 ` Mason 2015-05-18 11:24 ` Mason 2015-05-18 11:54 ` Russell King - ARM Linux 2015-05-20 16:21 ` Mason 2015-05-20 18:50 ` Arnd Bergmann 2015-05-20 19:34 ` Mason 2015-05-20 20:14 ` Russell King - ARM Linux 2015-05-20 20:41 ` Mason 2015-05-20 20:52 ` Arnd Bergmann 2015-05-20 21:56 ` Mason 2015-05-20 22:18 ` Arnd Bergmann 2015-05-21 12:35 ` Mason 2015-05-20 23:14 ` Russell King - ARM Linux 2015-05-21 9:56 ` Mason 2015-05-21 10:20 ` Russell King - ARM Linux 2015-05-14 14:48 ` Mason 2015-05-14 14:48 ` Mason 2015-05-15 4:16 ` Viresh Kumar 2015-05-15 4:16 ` Viresh Kumar 2015-05-15 5:07 ` Viresh Kumar 2015-05-15 5:07 ` Viresh Kumar 2015-05-15 9:00 ` Russell King - ARM Linux 2015-05-15 9:00 ` Russell King - ARM Linux 2015-05-15 9:21 ` Mason 2015-05-15 9:21 ` Mason 2015-05-15 10:11 ` Mason 2015-05-15 10:11 ` Mason 2015-05-12 15:23 ` Russell King - ARM Linux 2015-05-12 15:23 ` Russell King - ARM Linux 2015-05-12 16:03 ` Mason 2015-05-12 16:03 ` Mason
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=5555EA68.7030006@free.fr \ --to=slash.tmp@free.fr \ --cc=cpufreq@vger.kernel.org \ --cc=daniel.lezcano@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=mans@mansr.com \ --cc=rjw@rjwysocki.net \ --cc=viresh.kumar@linaro.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: linkBe 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.