[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1269464082.12097.3.camel@laptop>
Date: Wed, 24 Mar 2010 21:54:42 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Americo Wang <xiyou.wangcong@...il.com>,
Balbir Singh <balbir@...ibm.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Ingo Molnar <mingo@...e.hu>,
Roland McGrath <roland@...hat.com>,
Spencer Candland <spencer@...ehost.com>,
Stanislaw Gruszka <sgruszka@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC,PATCH 2/2] cputimers/proc:
do_task_stat()->thread_group_times() is racy and O(n) under ->siglock
On Wed, 2010-03-24 at 21:45 +0100, Oleg Nesterov wrote:
> Nowadays ->siglock is overloaded, it would be really nice to change
> do_task_stat() to walk through the list of threads lockless. And note
> that we are doing while_each_thread() twice!
>
> while_each_thread() is rcu-safe, but thread_group_times() also needs
> ->siglock to serialize the modifications of signal_struct->prev_Xtime
> members.
>
>
Right, so from what I remember the issue is that, yes top et al rely on
that monotonicity, but more importantly I think
clock_gettime(CLOCK_PROCESS_CPUTIME_ID) should indeed use ->siglock to
ensure it serializes against do_exit() so that either we iterate the
thread or get the accumulated runtime from signal_struct but not both
(or neither).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists