From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes
Date: Mon, 17 Jun 2013 15:21:26 -0700 [thread overview]
Message-ID: <51BF8BE6.5080704@codeaurora.org> (raw)
In-Reply-To: <51BF848B.2030501@linaro.org>
On 06/17/13 14:50, John Stultz wrote:
> On 06/17/2013 12:51 PM, Stephen Boyd wrote:
>> John,
>>
>> I just saw your pull request for making this code generic. I believe
>> this patch fixes a bug that nobody has seen in practice so it's probably
>> fine to delay this until 3.11.
>>
>> Also, I've just noticed that "ARM: sched_clock: Return suspended count
>> earlier" that I sent in that series is going to break the arm
>> architected timer path because they're circumventing all this epoch_ns
>> code. It would be better if you could replace that patch with this patch
>> because this optimizes it in the same way and also fixes a bug at the
>> same time.
>
> Sorry, could you clarify a bit more? The above sounds like there are
> two issues, but you only sent one patch.
I'm saying that the "return the suspended count earlier" patch is bad.
But this patch does what that patch is doing plus it fixes a race at the
same time. So it would be better to just take this patch and drop the other.
The problem is that when the cd.suspended flag is true we're going to
return the jiffies based sched_clock value for the ARM architected timer
driver (the only driver that replaces the sched_clock_func function
pointer with its own function). Jiffies should be pretty close to the
actual time anyway, but since the ARM architected timer driver is
already broken with respect to suspend (because it doesn't stop the
sched_clock value from incrementing during suspend) it doesn't really
matter. Every other driver using the sched_clock code will not be
affected either way.
>
> I'm also not sure how to proceed with the patch you sent, since it
> collides with the patch that moves sched_clock to be generic.
Ah I thought that the git rename detection would just make it work.
>
> Could you refactor the change on-top of git branch I sent to Thomas?
> Otherwise I'll have to withdraw the pull request, and we'll probably
> miss 3.11 for the generic sched_clock change.
Sure. I'll send it right now.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
prev parent reply other threads:[~2013-06-17 22:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 0:10 [PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes Stephen Boyd
2013-06-17 19:51 ` Stephen Boyd
2013-06-17 21:50 ` John Stultz
2013-06-17 22:21 ` Stephen Boyd [this message]
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=51BF8BE6.5080704@codeaurora.org \
--to=sboyd@codeaurora.org \
--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 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).