From: Oleg Nesterov <oleg@redhat.com>
To: Rik van Riel <riel@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,signal: protect resource use statistics with seqlock
Date: Thu, 14 Aug 2014 20:15:42 +0200 [thread overview]
Message-ID: <20140814181542.GB5091@redhat.com> (raw)
In-Reply-To: <53ECF390.40403@redhat.com>
On 08/14, Rik van Riel wrote:
>
> On 08/14/2014 12:12 PM, Oleg Nesterov wrote:
> >
> > Or you can expand the scope of write_seqlock/write_sequnlock, so that
> > __unhash_process in called from inside the critical section. This looks
> > simpler at first glance.
>
> The problem with that is that wait_task_zombie() calls
> thread_group_cputime_adjusted() in that if() branch, and
> that code ends up taking the seqlock for read...
Not sure I understand... This modifies parent->signal->c* counters,
and obviously the exiting thread is not the member of parent's thread
group, so thread_group_cputime_adjusted(parent) can never account the
exiting child twice simply because it won't see it?
> However, in __exit_signal that approach should work.
Yes,
> > Hmm, wait, it seems there is yet another problem ;) Afaics, you also
> > need to modify __exit_signal() so that ->sum_sched_runtime/etc are
> > accounted unconditionally, even if the group leader exits.
> >
> > Probably this is not a big problem, and sys_times() or clock_gettime()
> > do not care at all because they use current.
> >
> > But without this change thread_group_cputime(reaped_zombie) won't look
> > at this task_struct at all, this can lead to non-monotonic result if
> > it was previously called when this task was alive (non-reaped).
>
> You mean this whole block needs to run regardless of whether
> the group is dead?
>
> task_cputime(tsk, &utime, &stime);
> write_seqlock(&sig->stats_lock);
> sig->utime += utime;
> sig->stime += stime;
> sig->gtime += task_gtime(tsk);
> sig->min_flt += tsk->min_flt;
> sig->maj_flt += tsk->maj_flt;
> sig->nvcsw += tsk->nvcsw;
> sig->nivcsw += tsk->nivcsw;
> sig->inblock += task_io_get_inblock(tsk);
> sig->oublock += task_io_get_oublock(tsk);
> task_io_accounting_add(&sig->ioac, &tsk->ioac);
> sig->sum_sched_runtime += tsk->se.sum_exec_runtime;
Yes.
> How does that square with wait_task_zombie reaping the
> statistics of the whole group with thread_group_cputime_adjusted()
> when the group leader is exiting?
Again, not sure I understand... thread_group_cputime_adjusted() in
wait_task_zombie() is fine in any case. Nobody but us can reap this
zombie.
It seems that we misunderstood each other, let me try again. Just to
simplify, suppose we have, say,
sys_times_by_pid(pid, ...)
{
rcu_read_lock();
task = find_task_by_vpid(pid);
if (task)
get_task_struct(task);
rcu_read_unlock();
if (!task)
return -ESRCH;
thread_group_cputime(task, ...);
copy_to_user();
return 0;
}
Note that this task can exit right after rcu_read_unlock(), and it can
be also reaped (by its parent or by itself) and removed from the thread
list. In this case for_each_thread() will see no threads, and thus it
will only read task->signal->*time.
This means that sys_times_by_pid() can simply return the wrong result
instead of failure. Say, It can even return "all zeros" if this task was
single-threaded.
Oleg.
next prev parent reply other threads:[~2014-08-14 18:18 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
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 [this message]
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=20140814181542.GB5091@redhat.com \
--to=oleg@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=peterz@infradead.org \
--cc=riel@redhat.com \
--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.