From: Rik van Riel <riel@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: 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: drop do_sys_times spinlock
Date: Tue, 12 Aug 2014 18:27:41 -0400 [thread overview]
Message-ID: <53EA94DD.5040900@redhat.com> (raw)
In-Reply-To: <20140812191218.GA15210@redhat.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/12/2014 03:12 PM, Oleg Nesterov wrote:
> Afaics, the problem is that a single thread can observe the
> decreasing (say) sum_exec_runtime if it calls do_sys_times() twice
> without the lock.
>
> This is because it can account the exiting sub-thread twice if it
> races with __exit_signal() which increments sig->sum_sched_runtime,
> but this exiting thread can still be visible to
> thread_group_cputime().
>
> IOW, it is not actually about decreasing, the problem is that the
> lockless thread_group_cputime() can return the wrong result, and
> the next ys_times() can show the right value.
You are right, changing the test case to call times() many
times in a row in each thread can result in the wrong value
being returned.
Not entirely sure what I can do there...
Replacing the spinlock with a seqlock, and taking it for
write in most places is pretty gross, and may lead to other
issues like reader livelock when there is a lot of write
activity.
Having a seqlock just for the stats? Not sure the calls
to times() are a big enough issue for most workloads to
justify that...
Any other ideas?
- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJT6pTdAAoJEM553pKExN6DMrIIAKFFHD8luyqgVUAm0jbV8JHm
O5PD81kot95POV7ZAl6crKmPi0OoeSdZIzcmuLFIvRJWqrbgWY6h4rQH9va5B830
F7TC2PRzWwUVwcuEoaUkuZMbUWkWqzUwXcwwFl1blYmkVJVRF27VcUB4S0jia1eq
l2TlQyC1HgXa3E7rbQ6vuKsOq50jB08MWwxEfhAEMNvndhos/fvZlsxL39UO3/X7
AVk+V/leE5tfAfyr6uPrWDR7/u9sJkqmi/dGJ/xjfWNU2swEPvMXk6UhspSIY+mg
KAMa+JWTPANeUSRM9HRA9YUpo0rqvy0Azmg84tIYr4nXsIyvzHuRgCUNQkOmEDQ=
=5ap3
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-08-12 22:28 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 [this message]
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
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=53EA94DD.5040900@redhat.com \
--to=riel@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=fmayhar@google.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.