From: baruch@tkos.co.il (Baruch Siach)
To: linux-arm-kernel@lists.infradead.org
Subject: [Linux-Xtensa] Re: sched_clock always 0 and no process time accounting with 3.11-rc1
Date: Wed, 17 Jul 2013 09:47:09 +0300 [thread overview]
Message-ID: <20130717064709.GD6950@tarshish> (raw)
In-Reply-To: <CAMo8Bf+UY2Lj=7=Y2AxeUfM3LqJkbQqPviH81PEjwo8irtiGJg@mail.gmail.com>
Hi Max,
On Wed, Jul 17, 2013 at 10:39:51AM +0400, Max Filippov wrote:
> On Wed, Jul 17, 2013 at 10:19 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > On Mon, Jul 15, 2013 at 06:18:33PM +0400, Max Filippov wrote:
> >> with 3.11-rc1 printk timestamps are always zero (which means that
> >> sched_clock is always 0) and process time accounting always shows
> >> 0 for system/user time. I see it regardless of HZ_PERIODIC/NO_HZ_IDLE
> >> and HIGH_RES_TIMERS settings. Am I missing any necessary config
> >> options? Can you see the same issue?
> >
> > The following patch fixes the issue for me:
> >
> > diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> > index a326f27..0b479a6 100644
> > --- a/kernel/time/sched_clock.c
> > +++ b/kernel/time/sched_clock.c
> > @@ -121,7 +121,7 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
> > BUG_ON(bits > 32);
> > WARN_ON(!irqs_disabled());
> > read_sched_clock = read;
> > - sched_clock_mask = (1 << bits) - 1;
> > + sched_clock_mask = (1ULL << bits) - 1;
> > cd.rate = rate;
> >
> > /* calculate the mult/shift to convert counter ticks to ns. */
> >
> > Apparently the expression '(1 << 32)' evaluates to 1 on xtensa cross gcc, and
> > x86_64 native gcc. According to my limited understanding, the C compiler is
> > allowed to do so. This caused sched_clock_32() to return constant 0. I wonder
> > how it didn't bite the ARM people who are using this code from quite some time
> > (added LAKL to CC).
>
> Cool, it works now, thanks Baruch.
Thanks for testing.
> According to C99 the behaviour of (1 << 32) is undefined on platforms with
> 32 bit int, so it could yield any value.
But so is ARM, isn't it?
> > If this patch proves correct I'll send a formal patch to the timekeeping
> > maintainers.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
next prev parent reply other threads:[~2013-07-17 6:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAMo8BfLO31GgMMA_hENr0xm=qaUz3EVLtaQ8hewiQHdbV+s6sA@mail.gmail.com>
2013-07-17 6:19 ` sched_clock always 0 and no process time accounting with 3.11-rc1 Baruch Siach
2013-07-17 6:39 ` Max Filippov
2013-07-17 6:47 ` Baruch Siach [this message]
2013-07-17 7:02 ` [Linux-Xtensa] " Chris Zankel
2013-07-17 7:14 ` Baruch Siach
2013-07-17 9:03 ` Russell King - ARM Linux
2013-07-17 9:12 ` Baruch Siach
2013-07-17 9:15 ` Russell King - ARM Linux
2013-07-17 15:15 ` [Linux-Xtensa] " Marc Gauthier
2013-07-17 15:24 ` Russell King - ARM Linux
2013-07-17 16:17 ` Marc Gauthier
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=20130717064709.GD6950@tarshish \
--to=baruch@tkos.co.il \
--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).