From: Stanislav Meduna <stano@meduna.org>
To: Shawn Guo <shawn.guo@linaro.org>
Cc: "linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: scheduler clock for MXS [Was: Re: Wakeup latency measured with SCHED_TRACER depends on HZ]
Date: Mon, 05 Nov 2012 10:14:24 +0100 [thread overview]
Message-ID: <50978370.9060001@meduna.org> (raw)
In-Reply-To: <20121105025753.GA26528@S2100-06.ap.freescale.net>
On 05.11.2012 03:57, Shawn Guo wrote:
>> The patch in attach fixes this. I can only test the MX28 part -
>> I don't have any timrot_is_v1() (MX23) hardware and I don't
>> know whether a source that wraps after ~2 seconds is OK at all.
>
> From my quick testing on imx23 with printk timestamp, it's not OK,
> so we may need to leave imx23 out there.
Hmm, does it wrap after 2 seconds? From my grepping and googling
the code should now adapt itself, the hardcoded limit is gone...
What does the dmesg line such as
sched_clock: 32 bits at 32kHz, resolution 31250ns,
wraps every 134217727ms
output on that hardware?
Thanks for the comments, I will resubmit the corrected patch after
waiting ~1,5 days to verify correct wrapping with MX28.
Regards
--
Stano
WARNING: multiple messages have this Message-ID (diff)
From: stano@meduna.org (Stanislav Meduna)
To: linux-arm-kernel@lists.infradead.org
Subject: scheduler clock for MXS [Was: Re: Wakeup latency measured with SCHED_TRACER depends on HZ]
Date: Mon, 05 Nov 2012 10:14:24 +0100 [thread overview]
Message-ID: <50978370.9060001@meduna.org> (raw)
In-Reply-To: <20121105025753.GA26528@S2100-06.ap.freescale.net>
On 05.11.2012 03:57, Shawn Guo wrote:
>> The patch in attach fixes this. I can only test the MX28 part -
>> I don't have any timrot_is_v1() (MX23) hardware and I don't
>> know whether a source that wraps after ~2 seconds is OK at all.
>
> From my quick testing on imx23 with printk timestamp, it's not OK,
> so we may need to leave imx23 out there.
Hmm, does it wrap after 2 seconds? From my grepping and googling
the code should now adapt itself, the hardcoded limit is gone...
What does the dmesg line such as
sched_clock: 32 bits at 32kHz, resolution 31250ns,
wraps every 134217727ms
output on that hardware?
Thanks for the comments, I will resubmit the corrected patch after
waiting ~1,5 days to verify correct wrapping with MX28.
Regards
--
Stano
next prev parent reply other threads:[~2012-11-05 9:14 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-31 21:41 Wakeup latency measured with SCHED_TRACER depends on HZ Stanislav Meduna
2012-11-02 14:29 ` Stanislav Meduna
2012-11-05 2:57 ` Shawn Guo
2012-11-05 9:14 ` Stanislav Meduna [this message]
2012-11-05 9:14 ` scheduler clock for MXS [Was: Re: Wakeup latency measured with SCHED_TRACER depends on HZ] Stanislav Meduna
2012-11-05 13:46 ` Shawn Guo
2012-11-05 13:46 ` Shawn Guo
2012-11-05 16:09 ` Stanislav Meduna
2012-11-05 16:09 ` Stanislav Meduna
2012-11-05 22:28 ` Russell King - ARM Linux
2012-11-05 22:28 ` Russell King - ARM Linux
2012-11-06 2:40 ` Shawn Guo
2012-11-06 2:40 ` Shawn Guo
2012-11-06 10:12 ` Russell King - ARM Linux
2012-11-06 10:12 ` Russell King - ARM Linux
2012-11-06 13:49 ` Shawn Guo
2012-11-06 13:49 ` Shawn Guo
2012-11-06 20:04 ` Russell King - ARM Linux
2012-11-06 20:04 ` Russell King - ARM Linux
2012-11-06 8:34 ` scheduler clock for MXS Stanislav Meduna
2012-11-06 8:34 ` Stanislav Meduna
2012-11-06 9:45 ` Russell King - ARM Linux
2012-11-06 9:45 ` Russell King - ARM Linux
2012-11-06 13:46 ` Shawn Guo
2012-11-06 13:46 ` Shawn Guo
2012-11-06 20:20 ` Russell King - ARM Linux
2012-11-06 20:20 ` Russell King - ARM Linux
2012-11-06 22:30 ` Stanislav Meduna
2012-11-06 22:30 ` Stanislav Meduna
2012-11-06 22:46 ` Russell King - ARM Linux
2012-11-06 22:46 ` Russell King - ARM Linux
2012-11-07 7:13 ` Shawn Guo
2012-11-07 7:13 ` Shawn Guo
2012-11-08 21:27 ` Stanislav Meduna
2012-11-08 21:27 ` Stanislav Meduna
2012-11-08 22:11 ` Russell King - ARM Linux
2012-11-08 22:11 ` Russell King - ARM Linux
2012-11-08 22:45 ` [PATCH] ARM: mxs: Setup scheduler clock Stanislav Meduna
2012-11-08 22:45 ` Stanislav Meduna
2012-11-12 1:54 ` Shawn Guo
2012-11-12 1:54 ` Shawn Guo
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=50978370.9060001@meduna.org \
--to=stano@meduna.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=shawn.guo@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: 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.