From: Olivier Langlois <olivier@trillion01.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
schwidefsky@de.ibm.com, Steven Rostedt <rostedt@goodmis.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] process cputimer is moving faster than its corresponding clock
Date: Mon, 29 Apr 2013 13:16:28 -0400 [thread overview]
Message-ID: <1367255788.8833.7.camel@Wailaba2> (raw)
In-Reply-To: <517E125E.4050003@gmail.com>
On Mon, 2013-04-29 at 02:25 -0400, KOSAKI Motohiro wrote:
> (4/27/13 12:41 AM), Olivier Langlois wrote:
> >
> >
> > Add thread group delta to cpu timer sample when computing a timer expiration.
> >
> > This is mandatory to make sure that the posix cpu timer does not fire too
> > soon relative to the process cpu clock which do include the task group delta.
> >
> > test case to validate the patch is glibc-2.17/rt/tst-cputimer1.c
>
> First, I could reproduce this issue. thanks. Second, actually, this issue is not
> cause by race. This just occur by timer initialization mistake. I'll show you
> the smallest fix.
>
>
Great!
>
> > @@ -697,7 +755,8 @@ static int posix_cpu_timer_set(struct k_itimer *timer, int flags,
> > if (CPUCLOCK_PERTHREAD(timer->it_clock)) {
> > cpu_clock_sample(timer->it_clock, p, &val);
> > } else {
> > - cpu_timer_sample_group(timer->it_clock, p, &val);
> > + cpu_timer_sample_group(timer->it_clock, p, &val,
> > + CPUTIMER_NEED_DELTA);
>
> POSIX says,
>
> http://pubs.opengroup.org/onlinepubs/7908799/xsh/timer_gettime.html
> > If the argument ovalue is not NULL, the function timer_settime() stores,
> > in the location referenced by ovalue, a value representing the previous
> > amount of time before the timer would have expired or zero if the timer
> > was disarmed, together with the previous timer reload value. The members
> > of ovalue are subject to the resolution of the timer, and they are the
> > same values that would be returned by a timer_gettime() call at that point in time.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> but your posix_cpu_timer_set() and posix_cpu_timer_get() are not consistent. I'm worry
> about this.
>
>
> > }
> >
> > if (old) {
> > @@ -845,7 +904,8 @@ static void posix_cpu_timer_get(struct k_itimer *timer, struct itimerspec *itp)
> > read_unlock(&tasklist_lock);
> > goto dead;
> > } else {
> > - cpu_timer_sample_group(timer->it_clock, p, &now);
> > + cpu_timer_sample_group(timer->it_clock, p, &now,
> > + CPUTIMER_NO_DELTA);
> >
> > clear_dead = (unlikely(p->exit_state) &&
> > thread_group_empty(p));
> > }
>
> --
I have tried to minimize rq locks contention to strict minimum. If to
remain POSIX compliant, it is required to also use CPUTIMER_NEED_DELTA,
so be it. I have no objections.
next prev parent reply other threads:[~2013-04-29 17:16 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-05 17:59 [PATCH] process cputimer is moving faster than its corresponding clock Olivier Langlois
2013-04-10 11:35 ` Peter Zijlstra
2013-04-10 15:48 ` Olivier Langlois
2013-04-12 9:16 ` Peter Zijlstra
2013-04-15 1:55 ` Olivier Langlois
2013-04-12 9:18 ` Peter Zijlstra
2013-04-12 10:50 ` Peter Zijlstra
2013-04-12 15:55 ` Peter Zijlstra
2013-04-15 6:11 ` Olivier Langlois
2013-04-19 13:03 ` Frederic Weisbecker
2013-04-19 17:38 ` KOSAKI Motohiro
2013-04-19 18:08 ` KOSAKI Motohiro
2013-04-26 4:40 ` Olivier Langlois
2013-04-26 6:27 ` Olivier Langlois
2013-04-26 19:08 ` KOSAKI Motohiro
2013-04-27 1:51 ` Olivier Langlois
2013-04-27 2:15 ` KOSAKI Motohiro
2013-04-27 5:02 ` Olivier Langlois
2013-04-27 5:17 ` Olivier Langlois
2013-04-27 5:31 ` Olivier Langlois
2013-04-27 5:06 ` Olivier Langlois
2013-04-27 4:40 ` [PATCH v2 1/3] " Olivier Langlois
2013-04-29 0:45 ` Frederic Weisbecker
2013-04-29 17:29 ` Olivier Langlois
2013-04-29 5:06 ` KOSAKI Motohiro
2013-04-29 17:10 ` Olivier Langlois
2013-04-29 17:41 ` Olivier Langlois
2013-04-29 17:56 ` KOSAKI Motohiro
2013-04-29 18:20 ` Olivier Langlois
2013-04-29 18:31 ` KOSAKI Motohiro
2013-04-29 18:54 ` Olivier Langlois
2013-04-29 19:09 ` KOSAKI Motohiro
2013-04-29 21:20 ` Olivier Langlois
2013-04-29 22:42 ` KOSAKI Motohiro
[not found] ` <1367036552.7911.63.camel@Wailaba2>
2013-04-27 4:40 ` [PATCH v2 2/3] " Olivier Langlois
2013-04-27 4:41 ` [PATCH v2 3/3] " Olivier Langlois
2013-04-29 6:25 ` KOSAKI Motohiro
2013-04-29 17:16 ` Olivier Langlois [this message]
2013-04-11 3:29 ` [PATCH] " Olivier Langlois
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=1367255788.8833.7.camel@Wailaba2 \
--to=olivier@trillion01.com \
--cc=fweisbec@gmail.com \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
/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.