[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1258131903.22655.582.camel@laptop>
Date: Fri, 13 Nov 2009 18:05:03 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Stanislaw Gruszka <sgruszka@...hat.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
Américo Wang <xiyou.wangcong@...il.com>,
linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
Spencer Candland <spencer@...ehost.com>,
Balbir Singh <balbir@...ibm.com>
Subject: Re: [PATCH] sys_times: fix utime/stime decreasing on thread exit
On Fri, 2009-11-13 at 16:36 +0100, Stanislaw Gruszka wrote:
>
> But I don't like it much. Sad we can not do transition to opposite
> direction and remove task_{u,s}time.
We need task_[us]time() for some thing like process monitors like top to
avoid tasks hiding from them.
Since the regular [us]time are only incremented on tick, if a task never
runs on the tick, it'll never accumulate any tick and hence it'll be
reported as not using cpu time.
task_[us]time() solve this by using the ns sum_exec_runtime and scale
that according to the [us]time ticks -- the only trouble is keeping it
monotonic.
CONFIG_VIRT_CPU_ACCOUNTING avoids this whole issue by tracking time on
each user/kernel transition, but at the obvious cost of having to track
time at every such transition.
Now since we clearly don't want to incur that overhead on any regular
setup (kernel entry/exit paths are extremely hot), we're (afais) stuck
using the current scheme of dividing the sum_exec_runtime in two
components system/user according to the tick ratio.
Now if we can reduce the task_[us]time muckery to the bare minimum that
would be good, but the way it looks now all this accounting seems too
interwoven to pull that off.
--
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