A few functions use remote per CPU access APIs when they
deal with local values.
Just to the right conversion to improve performance, code
readability and debug checks.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Fernando Luis Vazquez Cao fernando...@lab.ntt.co.jp
Cc: Tetsuo Handa
-by: Frederic Weisbecker fweis...@gmail.com
Cc: Fernando Luis Vazquez Cao fernando...@lab.ntt.co.jp
Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Andrew Morton a...@linux-foundation.org
-by: Frederic Weisbecker fweis...@gmail.com
Cc: Fernando Luis Vazquez Cao fernando...@lab.ntt.co.jp
Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Andrew Morton a...@linux
On Fri, Aug 16, 2013 at 06:00:43PM +0200, Peter Zijlstra wrote:
OK so these patches look ok to me -- didn't read in detail though.
On Fri, Aug 16, 2013 at 05:42:33PM +0200, Frederic Weisbecker wrote:
A few functions use remote per CPU access APIs when they
deal with local values.
Just
On Fri, Aug 16, 2013 at 06:02:01PM +0200, Oleg Nesterov wrote:
Thanks Frederic!
I'll try to read this series carefully later. Not that I think
I can help, you certainly understand this much better.
Just one question below,
On 08/16, Frederic Weisbecker wrote:
@@ -499,12 +509,15
On Fri, Aug 16, 2013 at 06:02:01PM +0200, Oleg Nesterov wrote:
Thanks Frederic!
I'll try to read this series carefully later. Not that I think
I can help, you certainly understand this much better.
Just one question below,
On 08/16, Frederic Weisbecker wrote:
@@ -499,12 +509,15
On Fri, Aug 16, 2013 at 06:19:54PM +0200, Oleg Nesterov wrote:
On 08/16, Peter Zijlstra wrote:
OK so these patches look ok to me -- didn't read in detail though.
On Fri, Aug 16, 2013 at 05:42:33PM +0200, Frederic Weisbecker wrote:
A few functions use remote per CPU access APIs when
2013/8/16 Frederic Weisbecker fweis...@gmail.com:
On Fri, Aug 16, 2013 at 06:02:01PM +0200, Oleg Nesterov wrote:
Thanks Frederic!
I'll try to read this series carefully later. Not that I think
I can help, you certainly understand this much better.
Just one question below,
On 08/16
On Fri, Aug 16, 2013 at 06:26:54PM +0200, Oleg Nesterov wrote:
On 08/16, Frederic Weisbecker wrote:
On Fri, Aug 16, 2013 at 06:02:01PM +0200, Oleg Nesterov wrote:
+ do {
+ seq = read_seqcount_begin(ts-sleeptime_seq);
+ if (ts-idle_active
On Fri, Aug 16, 2013 at 06:33:55PM +0200, Oleg Nesterov wrote:
On 08/16, Frederic Weisbecker wrote:
On Fri, Aug 16, 2013 at 06:02:01PM +0200, Oleg Nesterov wrote:
Unless I missread this patch, this is still racy a bit.
Suppose it is called on CPU_0 and cpu == 1. Suppose that
ts
On Fri, Aug 16, 2013 at 06:49:22PM +0200, Oleg Nesterov wrote:
On 08/16, Frederic Weisbecker wrote:
tick_nohz_stop_idle() to iowait if we called tick_nohz_start_idle() with
nr_iowait 0.
All we need is just a new field in ts- that records on which state we
entered
idle.
Or we can
On Mon, Jul 15, 2013 at 03:36:46PM +0200, Mike Galbraith wrote:
(add cc)
On Mon, 2013-07-15 at 10:05 -0300, Dâniel Fraga wrote:
On Fri, 12 Jul 2013 08:52:27 +0200
Heinz Diehl h...@fancy-poultry.org wrote:
This describes exactly what I have encountered, and tickless idle
fixed it
On Mon, Jul 15, 2013 at 11:51:18AM -0300, Dâniel Fraga wrote:
On Mon, 15 Jul 2013 16:25:59 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
Hi,
Sorry I'm missing the description of the issue. Could you please
repaste it?
Thanks!
The problem is that when we use the new
Rostedt rost...@goodmis.org
AuthorDate: Fri May 10 17:12:28 2013 -0400
Committer: Frederic Weisbecker fweis...@gmail.com
CommitDate: Thu Jun 20 01:15:51 2013 +0200
nohz: Warn if the machine can not perform nohz_full
If the user configures NO_HZ_FULL and defines
On Mon, Jul 15, 2013 at 01:24:23PM -0400, Dave Jones wrote:
On Mon, Jul 15, 2013 at 07:18:02PM +0200, Frederic Weisbecker wrote:
So I guess you guys never want this to be enabled on distro kernels ?
If that's the case, can you add something to that effect in Kconfig ?
I believe
On Mon, Jul 15, 2013 at 01:38:48PM -0400, Dave Jones wrote:
On Mon, Jul 15, 2013 at 01:24:23PM -0400, Dave Jones wrote:
On Mon, Jul 15, 2013 at 07:18:02PM +0200, Frederic Weisbecker wrote:
So I guess you guys never want this to be enabled on distro kernels ?
If that's the case
On Mon, Jul 15, 2013 at 02:49:42PM -0400, Steven Rostedt wrote:
On Mon, 2013-07-15 at 13:38 -0400, Dave Jones wrote:
On Mon, Jul 15, 2013 at 01:24:23PM -0400, Dave Jones wrote:
On Mon, Jul 15, 2013 at 07:18:02PM +0200, Frederic Weisbecker wrote:
So I guess you guys never want
On Mon, Jul 15, 2013 at 03:30:20PM -0400, Steven Rostedt wrote:
On Mon, 2013-07-15 at 14:56 -0400, Dave Jones wrote:
On Mon, Jul 15, 2013 at 02:49:42PM -0400, Steven Rostedt wrote:
Is a printk not enough for that purpose ? Tainting the kernel is kinda
anti-social.
printk's don't
On Tue, Jun 18, 2013 at 12:36:32PM +0200, Peter Zijlstra wrote:
On Thu, Jun 13, 2013 at 10:02:07AM -0400, Don Zickus wrote:
On Thu, Jun 13, 2013 at 03:10:59PM +0200, Frederic Weisbecker wrote:
On Wed, Jun 12, 2013 at 01:03:16PM -0400, Don Zickus wrote:
On Wed, Jun 12, 2013 at 04:02:36PM
you think using per-cpu is a problem. It's not only
deemed for optimized local uses, it's also convenient for allocations and
de-allocation, or static definitions. I'm not sure why bootmem would make
more sense.
Other than this in the changelog, the patch is nice, thanks!
Acked-by: Frederic
current time (aka cpu clock time) because
an expires should be now + timeout by definition.
This patch distinguishes between two kinds of now.
Cc: Olivier Langlois oliv...@trillion01.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi
, 64bit can avoid holding rq lock when add_delta is false and
delta_exec is 0.
Cc: Olivier Langlois oliv...@trillion01.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Suggested-by: Paul Turner p...@google.com
Acked
On Tue, Jun 18, 2013 at 08:15:20AM -0700, Paul E. McKenney wrote:
On Tue, Jun 18, 2013 at 02:20:35PM +, Christoph Lameter wrote:
On Wed, 12 Jun 2013, Frederic Weisbecker wrote:
Here it is, a very basic test that runs a userspace loop for ten seconds
and dumps a trace
On Tue, Jun 18, 2013 at 04:42:25PM +0200, Oleg Nesterov wrote:
On 06/18, Frederic Weisbecker wrote:
On Sun, Jun 02, 2013 at 09:50:57PM +0200, Oleg Nesterov wrote:
This patch simply moves all per-cpu variables into the new single
per-cpu struct bp_cpuinfo.
To me this looks more
On Tue, Jun 18, 2013 at 11:17:41AM -0400, KOSAKI Motohiro wrote:
+#ifdef CONFIG_64BIT
+ /*
+ * 64-bit doesn't need locks to atomically read a 64bit value. So we
+ * have two optimization chances, 1) when caller doesn't need
+ * delta_exec and 2) when the task's
On Tue, Jun 18, 2013 at 11:17:33AM -0700, Paul E. McKenney wrote:
On Tue, Jun 18, 2013 at 06:22:57PM +0200, Frederic Weisbecker wrote:
On Tue, Jun 18, 2013 at 08:15:20AM -0700, Paul E. McKenney wrote:
On Tue, Jun 18, 2013 at 02:20:35PM +, Christoph Lameter wrote:
On Wed, 12 Jun 2013
() returns KTIME_MAX.)
Cc: Frederic Weisbecker fweis...@gmail.com
Signed-off-by: Kevin Hilman khil...@linaro.org
This looks like a useful thing but I wonder if a debugfs file would
be more appropriate than sysctl.
The scheduler tick max deferment is supposed to be a temporary
hack so we
platform when extending the max
deferment value.
Cc: Frederic Weisbecker fweis...@gmail.com
Signed-off-by: Kevin Hilman khil...@linaro.org
Right, if we make it tunable we need that patch.
Thanks!
Acked-by: Frederic Weisbecker fweis...@gmail.com
---
kernel/sched/core.c | 2 +-
1 file changed, 1
On Tue, Jun 18, 2013 at 11:12:17AM -0400, KOSAKI Motohiro wrote:
On Tue, Jun 18, 2013 at 10:20 AM, Frederic Weisbecker
fweis...@gmail.com wrote:
On Sun, May 26, 2013 at 05:35:44PM -0400, kosaki.motoh...@gmail.com wrote:
From: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
Currently
on it. But since I'll be off next week, I prefer to have
at least a working temporary solution before the next merge window.
Thanks,
Frederic
---
Frederic Weisbecker (4):
watchdog: Register / unregister watchdog kthreads on sysctl control
watchdog: Rename confusing state variable
this patchset can help starting a discussion.
Those who want to play can fetch from:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
sched/core
Thanks,
Frederic
---
Frederic Weisbecker (4):
sched: Disable lb_bias feature for full dynticks
preempt_schedule() and preempt_schedule_context() open
code their preemptability checks.
Use the standard API instead for consolidation.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Li Zhong zh...@linux.vnet.ibm.com
Cc: Paul E. McKenney paul
Gather the common code that computes the pending idle cpu load
to decay.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Li Zhong zh...@linux.vnet.ibm.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Steven
as it is currently the only user of the decayed
load records.
The first load index that represents the current runqueue load weight
is still maintained and usable.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Li Zhong zh...@linux.vnet.ibm.com
Cc: Paul E. McKenney
Now that the decaying cpu load stat indexes used by LB_BIAS
are ignored in full dynticks mode, let's conditionally build
that code to optimize the off case.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Li Zhong zh...@linux.vnet.ibm.com
Cc: Paul E
On Tue, Jul 16, 2013 at 10:22:12AM -0400, Steven Rostedt wrote:
If the user enables CONFIG_NO_HZ_FULL and runs the kernel on a machine
with an unstable TSC, it will produce a WARN_ON dump as well as taint
the kernel. This is a bit extreme for a kernel that just enables a
feature but doesn't
On Tue, Jul 16, 2013 at 12:18:47PM +0800, Li Zhong wrote:
cpu is not used after commit 5b8621a68fdcd2baf1d3b413726f913a5254d46a
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
Applied, thanks!
---
kernel/time/tick-sched.c | 2 --
1 file changed, 2 deletions(-)
diff --git
to take care of: let the boot CPU
go idle as well in the off case.
I also hope we'll get Paul's patches that allow the timekeeper to go
idle in 3.12, but that's another story.
---
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
timers/nohz-3.12-preview
Frederic
This can be useful to track all kernel/user round trips.
And it's also helpful to debug the context tracking subsystem.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc
Prepare for using a static key in the context tracking subsystem.
This will help optimizing the off case on its many users:
* user_enter, user_exit, exception_enter, exception_exit, guest_enter,
guest_exit, vtime_*()
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost
If no CPU is in the full dynticks range, we can avoid the full
dynticks cputime accounting through generic vtime along with its
overhead and use the traditional tick based accounting instead.
Let's do this and nope the off case with static keys.
Signed-off-by: Frederic Weisbecker fweis
short.
Fix vtime_account_user() that wasn't complying to that rule.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra
useless.
This is easily fixable by moving the snapshot origin update after
the call to get_vtime_delta(). The order doesn't matter there.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi
the periodic interrupt.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc: Borislav Petkov b
in vtime.h later.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc: Borislav Petkov b...@alien8.de
Cc
No need for syscall slowpath if no CPU is full dynticks,
rather nop this in this case.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t
Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc: Borislav Petkov b...@alien8.de
Cc: Li Zhong zh...@linux.vnet.ibm.com
Cc: Mike Galbraith efa...@gmx.de
Cc: Kevin Hilman khil...@linaro.org
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
kernel/time/tick-sched.c |2 --
1
tracking itself is still necessary everywhere.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc
in the long term, we'll need
to bring an exception slow path by re-routing the exception
handlers.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t
Update a stale comment from the old vtime era and document some
locking that might be non obvious.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t
Some generic vtime APIs check if the vtime accounting
is enabled on the local CPU before doing their work.
Some of these are not needed because all their callers already
take care of that. Let's remove the checks on these.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt
combinations
finally work.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc: Borislav Petkov
tracking even on CPUs
that are not in the full dynticks range. OTOH we can spare the
rcu_user_*() and vtime_user_*() calls there because the tick runs
on these CPUs and we can handle RCU state machine and cputime
accounting through it.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven
Galbraith efa...@gmx.de
Cc: Kevin Hilman khil...@linaro.org
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
kernel/time/tick-sched.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6960172..6f47049 100644
preempt_schedule() and preempt_schedule_context() open
code their preemptability checks.
Use the standard API instead for consolidation.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Li Zhong zh...@linux.vnet.ibm.com
Cc: Paul E. McKenney paul
If the arch overrides some generic vtime APIs, let it describe
these on a dedicated and standalone header. This way it becomes
convenient to include it in vtime generic headers without irrelevant
stuff in such a low level header.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven
On Mon, Jul 08, 2013 at 06:30:05PM -0700, Paul E. McKenney wrote:
}
/*
+ * Unconditionally force exit from full system-idle state. This is
+ * invoked when a normal CPU exits idle, but must be called separately
+ * for the timekeeping CPU (tick_do_timer_cpu). The reason for this
+ *
On Wed, Jul 17, 2013 at 05:41:41PM -0700, Paul E. McKenney wrote:
On Thu, Jul 18, 2013 at 01:31:21AM +0200, Frederic Weisbecker wrote:
I'm missing a key here.
Let's imagine that the timekeeper has finally set full_sysidle_state =
RCU_SYSIDLE_FULL_NOTED
with cmpxchg, what guarantees
On Wed, Jul 17, 2013 at 08:39:21PM -0700, Paul E. McKenney wrote:
On Thu, Jul 18, 2013 at 03:33:01AM +0200, Frederic Weisbecker wrote:
So it's like:
CPU 0 CPU 1
read I write I
smp_mb
On Wed, Jul 17, 2013 at 01:57:51PM -0400, Steven Rostedt wrote:
On Wed, 2013-07-17 at 18:44 +0200, Frederic Weisbecker wrote:
Update a stale comment from the old vtime era and document some
locking that might be non obvious.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc
On Wed, Jul 17, 2013 at 02:27:17PM -0400, Steven Rostedt wrote:
On Wed, 2013-07-17 at 18:44 +0200, Frederic Weisbecker wrote:
The code is ready to do so in the context tracking subsystem, now
do so? Do what?
It's referring to the patch title. The code is ready to selectively
enable context
On Thu, Jul 18, 2013 at 09:47:49AM -0700, Paul E. McKenney wrote:
On Thu, Jul 18, 2013 at 04:24:51PM +0200, Frederic Weisbecker wrote:
On Wed, Jul 17, 2013 at 08:39:21PM -0700, Paul E. McKenney wrote:
On Thu, Jul 18, 2013 at 03:33:01AM +0200, Frederic Weisbecker wrote:
So it's like
On Thu, Jul 18, 2013 at 05:24:08PM -0700, Paul E. McKenney wrote:
On Fri, Jul 19, 2013 at 12:46:21AM +0200, Frederic Weisbecker wrote:
On Thu, Jul 18, 2013 at 09:47:49AM -0700, Paul E. McKenney wrote:
1. Some CPU coming out of idle:
o rcu_sysidle_exit
On Thu, Jul 18, 2013 at 06:51:57PM -0400, Steven Rostedt wrote:
On Fri, 2013-07-19 at 00:13 +0200, Frederic Weisbecker wrote:
On Wed, Jul 17, 2013 at 02:27:17PM -0400, Steven Rostedt wrote:
On Wed, 2013-07-17 at 18:44 +0200, Frederic Weisbecker wrote:
The code is ready to do so
On Mon, Sep 09, 2013 at 12:53:47PM +0200, Peter Zijlstra wrote:
On Fri, Sep 06, 2013 at 08:59:29PM +0200, Frederic Weisbecker wrote:
Imagine that you're running on an rcu read side critical section on CPU 0,
which
is not in extended quiescent state. Now you get preempted in the middle
On Mon, Sep 09, 2013 at 08:39:26AM -0400, Steven Rostedt wrote:
On Mon, 9 Sep 2013 14:13:31 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
In any case the preempt_disable/enable pair there is just plain wrong as
Eric pointed out.
Check
On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
On Mon, 9 Sep 2013 14:45:49 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
This just proves that the caller of rcu_is_cpu_idle() must disable
preemption itself for the entire time that it needs to use the result
On Mon, Sep 09, 2013 at 03:14:52PM +0200, Peter Zijlstra wrote:
On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
On Mon, 9 Sep 2013 14:45:49 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
This just proves that the caller of rcu_is_cpu_idle() must disable
On Mon, Sep 09, 2013 at 09:21:42AM -0400, Steven Rostedt wrote:
On Mon, 9 Sep 2013 15:08:53 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
From reading the context a bit more, it seems that the per cpu value is
more
On Mon, Sep 09, 2013 at 09:41:32AM -0400, Steven Rostedt wrote:
On Mon, 9 Sep 2013 15:29:02 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
No, putting that on the task_struct won't help much in this regard I think.
Regular schedule() calls don't change that per cpu state
On Mon, Sep 09, 2013 at 09:29:17AM -0400, Steven Rostedt wrote:
On Mon, 9 Sep 2013 09:21:42 -0400
Steven Rostedt rost...@goodmis.org wrote:
Especially since the function name itself is rcu_is_cpu_idle() which
tells you it's a cpu state, and not a task state. Why would you care in
RCU
On Mon, Sep 09, 2013 at 11:39:05AM -0400, Steven Rostedt wrote:
On Mon, 9 Sep 2013 11:20:57 -0400
Steven Rostedt rost...@goodmis.org wrote:
It's a bit the same with spinlocks. spinlocks aren't a task
synchronization
but a CPU synchronization. It's low level. Of course a task can't
On Tue, Sep 10, 2013 at 05:06:06PM +0900, Namhyung Kim wrote:
Hi,
On Thu, 5 Sep 2013 14:42:44 +0200, Frederic Weisbecker wrote:
On Thu, Sep 05, 2013 at 12:56:39PM +0200, Ingo Molnar wrote:
(Cc:-ed Frederic and Namhyung as well, it's about bad overhead in
tools/perf/util/hist.c
On Tue, Sep 10, 2013 at 12:25:54PM +0200, Ingo Molnar wrote:
* Jiri Olsa jo...@redhat.com wrote:
On Tue, Sep 10, 2013 at 05:24:16PM +0900, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Current collapse stage has a scalability problem which can be
reproduced easily
On Tue, Sep 10, 2013 at 05:24:15PM +0900, Namhyung Kim wrote:
Hello,
Linus reported that perf report was stuck in after processing time
ordered events. It turned out that merging/collapsing the callchain
takes most of time to look up a matching callchain. Since it did a
linear search for
On Wed, Sep 11, 2013 at 02:21:06PM +, Christoph Lameter wrote:
On Wed, 11 Sep 2013, Mike Galbraith wrote:
Mind saying why? To me, creating properties of exclusive sets of CPUs
that the interface which manages sets and their properties is not fully
aware of is a dainbramaged thing to
On Thu, Sep 05, 2013 at 08:07:37PM +, Christoph Lameter wrote:
I am not sure how to call this kernel option but we need something like
that. I see drivers and the kernel spawning processes on the nohz cores.
The name kthread is not really catching the purpose.
os_cpus=?
On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Why not do this from userspace instead?
Because the cpumasks are hardcoded in the kernel code.
Ok but you can change the affinity of a kthread from userspace, as
long
On Thu, Sep 12, 2013 at 02:22:43PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
On Thu, Sep 12, 2013 at 02:10:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Why not do this from userspace instead?
Because
On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Ok but you can change the affinity of a kthread from userspace, as
long as you define a cpu set that is among that kthread's cpus allowed.
Ok but at that point
On Thu, Sep 12, 2013 at 08:39:22AM -0700, Paul E. McKenney wrote:
On Thu, Sep 12, 2013 at 05:11:04PM +0200, Frederic Weisbecker wrote:
On Thu, Sep 12, 2013 at 02:52:56PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Ok but you can change
On Thu, Sep 12, 2013 at 03:32:20PM +, Christoph Lameter wrote:
On Thu, 12 Sep 2013, Frederic Weisbecker wrote:
Yea but the kernel option makes it easy. No extras needed. Kernel brings
it up user space cleanly configured and ready to go.
Ok but really that's just two lines of bash
On Thu, Sep 12, 2013 at 03:42:21PM +, Christoph Lameter wrote:
Let me just say that the user space approach does not work because the
kernel sets the cpumask to all and then spawns a thread f.e. for
usermodehelper.
This mean we would have to run a daemon that keeps scanning for errand
Now that comm strings are allocated only once and refcounted to be shared
among threads, these can now be safely compared by addresses. This
should remove most hists collapses on post processing.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
Cc: David Ahern
that with Namhyung callchains patches could provide some
cumulative nice results.
thanks.
---
Frederic Weisbecker (4):
perf tools: Use an accessor to read thread comm
perf tools: Add time argument on comm setting
perf tools: Add new comm infrastructure
perf tools: Compare
way
to keep track of all the comms lifecycles in a thread without
time informations.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
Cc: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Namhyung Kim namhy...@kernel.org
Cc: Peter Zijlstra a.p.zijls
-by: Frederic Weisbecker fweis...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
Cc: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Namhyung Kim namhy...@kernel.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Arnaldo Carvalho de Melo a...@redhat.com
Cc: Stephane Eranian eran...@google.com
implementation.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
Cc: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Namhyung Kim namhy...@kernel.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Arnaldo Carvalho de Melo a...@redhat.com
Cc: Stephane
Optimize guest entry/exit APIs with static keys. This minimize
the overhead for those who enable CONFIG_NO_HZ_FULL without
always using it. Having no range passed to nohz_full= should
result in the probes overhead to be minimized.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven
Some generic vtime APIs check if the vtime accounting
is enabled on the local CPU before doing their work.
Some of these are not needed because all their callers already
take care of that. Let's remove the checks on these.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt
term, we'll need
to bring an exception slow path by re-routing the exception
handlers.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t
Scheduler IPIs and task context switches are serious fast path.
Let's try to hide as much as we can the impact of full
dynticks APIs' off case that are called on these sites
through the use of static keys.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost
useless.
This is easily fixable by moving the snapshot origin update after
the call to get_vtime_delta(). The order doesn't matter there.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi
in vtime.h later.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc: Borislav Petkov b...@alien8.de
Cc
Rename the full dynticks's cpumask and cpumask state variables
to some more exportable names.
These will be used later from global headers to optimize
the main full dynticks APIs in conjunction with static keys.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost
These APIs are frequenctly accessed and priority is given
to optimize the full dynticks off-case in order to let
distros enable this feature without suffering from
significant performance regressions.
Let's inline these APIs and optimize them with static keys.
Signed-off-by: Frederic Weisbecker
If the arch overrides some generic vtime APIs, let it describe
these on a dedicated and standalone header. This way it becomes
convenient to include it in vtime generic headers without irrelevant
stuff in such a low level header.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven
If no CPU is in the full dynticks range, we can avoid the full
dynticks cputime accounting through generic vtime along with its
overhead and use the traditional tick based accounting instead.
Let's do this and nope the off case with static keys.
Signed-off-by: Frederic Weisbecker fweis
the periodic interrupt.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc: Borislav Petkov b
vtime.h will expand to use static keys.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Steven Rostedt rost...@goodmis.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Peter Zijlstra pet...@infradead.org
Cc: Borislav
901 - 1000 of 8299 matches
Mail list logo
