From: Rik van Riel <riel@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>,
Frank Mayhar <fmayhar@google.com>,
Frederic Weisbecker <fweisbec@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Sanjay Rao <srao@redhat.com>, Larry Woodman <lwoodman@redhat.com>
Subject: Re: [PATCH RFC] time,signal: protect resource use statistics with seqlock
Date: Wed, 13 Aug 2014 21:57:01 -0400 [thread overview]
Message-ID: <53EC176D.6080201@redhat.com> (raw)
In-Reply-To: <20140814004318.GA2582@lerouge>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
> On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
>> --- a/kernel/time/posix-cpu-timers.c +++
>> b/kernel/time/posix-cpu-timers.c @@ -272,22 +272,8 @@ static int
>> posix_cpu_clock_get_task(struct task_struct *tsk, if
>> (same_thread_group(tsk, current)) err =
>> cpu_clock_sample(which_clock, tsk, &rtn); } else { - unsigned
>> long flags; - struct sighand_struct *sighand; - - /* - *
>> while_each_thread() is not yet entirely RCU safe, - * keep
>> locking the group while sampling process - * clock for now. -
>> */ - sighand = lock_task_sighand(tsk, &flags); - if (!sighand)
>> - return err; - if (tsk == current ||
>> thread_group_leader(tsk)) err =
>> cpu_clock_sample_group(which_clock, tsk, &rtn); - -
>> unlock_task_sighand(tsk, &flags); }
>
> I'm worried about such lockless solution based on RCU or read
> seqcount because we lose the guarantee that an update is
> immediately visible by all subsequent readers.
>
> Say CPU 0 updates the thread time and both CPU 1 and CPU 2 right
> after that call clock_gettime(), with the spinlock we were
> guaranteed to see the new update. Now with a pure seqlock read
> approach, we guarantee a read sequence coherency but we don't
> guarantee the freshest update result.
>
> So that looks like a source of non monotonic results.
Which update are you worried about, specifically?
The seq_write_lock to update the usage stat in p->signal will lock out
the seqlock read side used to check those results.
Is there another kind of thing read by cpu_clock_sample_group that you
believe is not excluded by the seq_lock?
- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJT7BdtAAoJEM553pKExN6DngEH/1CJuBb6xij08AoZNQuW4WNQ
geKakADsYTz8FmutbGi+lJEHNKAMZQ5wYbyFNczPAX/fVJsOlC92Qtfwy5z/VupN
QzlRHh79ZJR5/6xGddlu/8LjGrMIXwKqShIeKtTzoENS+rxA82l42zoXTagal4yX
Peb5/Q7cBMg9pFZzUMITEJssQhDtyTN1rXiU5IsEG54PhDbSgFk7HK1cO46tRefb
x1WbUKZKUViVKnoKYhJqd6FDSWuPtL5EpebvMVj9TZ29JBQTMDGx8saUezjuY0YL
STAv/wqigmbbcNnloJpr3gO1iJMkknv3jHk6Bfv1Dil8Um1D3mBAAKFK+Ov8Rk0=
=kU1O
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-08-14 1:57 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-12 18:25 [PATCH RFC] time: drop do_sys_times spinlock Rik van Riel
2014-08-12 19:12 ` Oleg Nesterov
2014-08-12 19:22 ` Rik van Riel
2014-08-12 22:27 ` Rik van Riel
2014-08-13 17:22 ` Oleg Nesterov
2014-08-13 17:35 ` Rik van Riel
2014-08-13 18:08 ` Oleg Nesterov
2014-08-13 18:25 ` Rik van Riel
2014-08-13 18:45 ` Oleg Nesterov
2014-08-13 18:57 ` Rik van Riel
2014-08-13 21:03 ` [PATCH RFC] time,signal: protect resource use statistics with seqlock Rik van Riel
2014-08-14 0:43 ` Frederic Weisbecker
2014-08-14 1:57 ` Rik van Riel [this message]
2014-08-14 13:34 ` Frederic Weisbecker
2014-08-14 14:39 ` Oleg Nesterov
2014-08-15 2:52 ` Frederic Weisbecker
2014-08-15 14:26 ` Oleg Nesterov
2014-08-15 22:33 ` Frederic Weisbecker
2014-08-14 13:22 ` Oleg Nesterov
2014-08-14 13:38 ` Frederic Weisbecker
2014-08-14 13:53 ` Oleg Nesterov
2014-08-14 17:48 ` Oleg Nesterov
2014-08-14 18:34 ` Oleg Nesterov
2014-08-15 5:19 ` Mike Galbraith
2014-08-15 6:28 ` Peter Zijlstra
2014-08-15 9:37 ` Mike Galbraith
2014-08-15 9:44 ` Peter Zijlstra
2014-08-15 16:36 ` Oleg Nesterov
2014-08-15 16:49 ` Oleg Nesterov
2014-08-15 17:25 ` Rik van Riel
2014-08-15 18:36 ` Oleg Nesterov
2014-08-14 14:24 ` Oleg Nesterov
2014-08-14 15:37 ` Rik van Riel
2014-08-14 16:12 ` Oleg Nesterov
2014-08-14 17:36 ` Rik van Riel
2014-08-14 18:15 ` Oleg Nesterov
2014-08-14 19:03 ` Rik van Riel
2014-08-14 19:37 ` Oleg Nesterov
2014-08-15 2:14 ` Rik van Riel
2014-08-15 14:58 ` Oleg Nesterov
2014-08-13 21:03 ` Rik van Riel
2014-08-13 17:40 ` [PATCH RFC] time: drop do_sys_times spinlock Peter Zijlstra
2014-08-13 17:50 ` Rik van Riel
2014-08-13 17:53 ` Peter Zijlstra
2014-08-13 6:59 ` Mike Galbraith
2014-08-13 11:11 ` Peter Zijlstra
2014-08-13 13:24 ` Rik van Riel
2014-08-13 13:39 ` Peter Zijlstra
2014-08-13 14:09 ` Mike Galbraith
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=53EC176D.6080201@redhat.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=fmayhar@google.com \
--cc=fweisbec@gmail.com \
--cc=fweisbec@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lwoodman@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=seto.hidetoshi@jp.fujitsu.com \
--cc=srao@redhat.com \
/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.