[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F73336C.3020603@tilera.com>
Date: Wed, 28 Mar 2012 11:51:08 -0400
From: Chris Metcalf <cmetcalf@...era.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Christoph Lameter <cl@...ux.com>,
Frederic Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
<linaro-sched-sig@...ts.linaro.org>,
Alessio Igor Bogani <abogani@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Avi Kivity <avi@...hat.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Geoff Levand <geoff@...radead.org>,
Gilad Ben Yossef <gilad@...yossef.com>,
Ingo Molnar <mingo@...nel.org>,
Max Krasnyansky <maxk@...lcomm.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Stephen Hemminger <shemminger@...tta.com>,
Steven Rostedt <rostedt@...dmis.org>,
Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Zen Lin <zen@...nhuawei.org>,
Dimitri Sivanich <sivanich@....com>
Subject: Re: [PATCH 08/32] nohz: Try not to give the timekeeping duty to an
adaptive tickless cpu
On 3/28/2012 4:39 AM, Peter Zijlstra wrote:
>> It would seem that the nohz patches would be much simpler if it would not
>> > require cpusets to administer. The only thing that would be needed is to
>> > have one cpu that is not subject to nohz. The logical choice is a
>> > timekeeper cpu (which is usually cpu 0). Having that configurable would be
>> > an extra bonus.
> Like Frederic has been telling, the nohz stuff adds syscall overhead, it
> needs to timestamp on kernel entry/exit etc.. Making it unconditional
> will add this overhead to everybody and this might not be acceptable.
And more generally, some kind of configuration step is important so the
kernel knows what userspace wants to have happen there. On a nohz cpu the
kernel will try to optimize for running a single task with no OS overhead.
On a default cpu the kernel will be trying to use the cpu as part of a pool
for optimizing the overall system experience, including work stealing,
background threads, etc. This could be a per-process thing, or it could be
a per-core thing, but either way, the kernel can't really guess effectively.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
--
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