Re: [RFC PATCH 0/3] irq: Fix stack overflow due to softirq called on current stack

2013/9/18 Paul Mackerras : > Frederic, > > On Thu, Sep 05, 2013 at 05:33:21PM +0200, Frederic Weisbecker wrote: >> >> This series is a proposition to fix the crash reported here: >> http://lkml.kernel.org/r/1378330796.4321.50.camel%40pasglop >> And it has the ups

[PATCH 3/3] irq: Comment on the use of inline stack for ksoftirqd

Ksoftirqd shouldn't need softirq stack since it's executing in a kernel thread with a callstack that is only beginning at this stage. Lets comment about that for clarity. Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gl

[PATCH 2/3] irq: Execute softirq on its own stack on irq exit

minimize this. Reported-by: Benjamin Herrenschmidt Signed-off-by: Frederic Weisbecker Tested-by: Paul Mackerras Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Paul Mackerras Cc: James Hogan

[PATCH 1/3] irq: Consolidate do_softirq() arch overriden implementations

Herrenschmidt Signed-off-by: Frederic Weisbecker Tested-by: Paul Mackerras Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Paul Mackerras Cc: James Hogan Cc: James E.J. Bottomley Cc: Helge Deller Cc

[RFC GIT PULL] softirq: Consolidation and stack overrun fix

hanks. --- Frederic Weisbecker (3): irq: Consolidate do_softirq() arch overriden implementations irq: Execute softirq on its own stack on irq exit irq: Comment on the use of inline stack for ksoftirqd arch/metag/kernel/irq.c| 56 ++- arch/parisc/k

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

On Fri, Sep 20, 2013 at 01:03:17PM +0200, Thomas Gleixner wrote: > On Thu, 19 Sep 2013, Linus Torvalds wrote: > > > On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker > > wrote: > > > > > > It fixes stacks overruns reported by Benjamin Herrensch

Re: RFC vmstat: On demand vmstat threads

On Fri, Sep 20, 2013 at 12:41:02PM +0200, Thomas Gleixner wrote: > On Thu, 19 Sep 2013, Christoph Lameter wrote: > > On Thu, 19 Sep 2013, Thomas Gleixner wrote: > > > > > The vmstat accounting is not the only thing which we want to delegate > > > to dedicated core(s) for the full NOHZ mode. > > >

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

On Fri, Sep 20, 2013 at 07:30:14PM +0200, Thomas Gleixner wrote: > On Fri, 20 Sep 2013, Frederic Weisbecker wrote: > > > Now just for clarity, what do we then do with inline sofirq > > executions: on local_bh_enable() for example, or explicit calls to > > do_softirq() othe

Re: [tip:timers/urgent] sched/cputime: Do not scale when utime == 0

ference: > > https://lkml.org/lkml/2013/8/20/259 > > Reported-and-tested-by: Sergey Senozhatsky > Signed-off-by: Stanislaw Gruszka > Cc: sta...@vger.kernel.org > Cc: Frederic Weisbecker > Cc: Peter Zijlstra > Cc: Paul E. McKenney > Cc: Borislav Petkov > Link

Re: [GIT PULL] perf changes for v3.12

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.) > > * Linus Torvalds wrote: > > > On Tue, Sep 3, 2013 at 6:29 AM, Ingo Molnar wrote: > > > > > > Please pull the latest perf-core-for-l

Re: [GIT PULL] perf changes for v3.12

On Thu, Sep 05, 2013 at 02:51:01PM +0200, Ingo Molnar wrote: > > * Frederic Weisbecker wrote: > > > > Btw., a side note, append_chain() is a rather confusing function in > > > itself, with logic-inversion gems like: > > > > > > if

Re: do_softirq() vs __do_softirq() in irq_exit() and stack overflow

On Thu, Sep 05, 2013 at 07:39:56AM +1000, Benjamin Herrenschmidt wrote: > Hi Folks ! > > It appears that the current version of irq_exit() calls __do_softirq() > directly rather than do_softirq(). > > That means we are going to call the softirq's in the current interrupt > frame rather than on th

[PATCH 3/3] irq: Comment on the use of inline stack for ksoftirq

Ksoftirqd shouldn't need softirq stack since it's executing in a kernel thread with a callstack that is only beginning at this stage. Lets comment about that for clarity. Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gl

[PATCH 1/3] irq: Consolidate do_softirq() arch overriden implementations

ff-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Paul Mackerras Cc: James Hogan Cc: James E.J. Bottomley Cc: Helge Deller Cc: Martin Schwidefsky Cc: Heiko Carsten

[PATCH 2/3] irq: Execute softirq on its own stack on irq exit

minimize this. Reported-by: Benjamin Herrenschmidt Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Paul Mackerras Cc: James Hogan Cc: James E.J. Bottomley

[RFC PATCH 0/3] irq: Fix stack overflow due to softirq called on current stack

Hi, This series is a proposition to fix the crash reported here: http://lkml.kernel.org/r/1378330796.4321.50.camel%40pasglop And it has the upside to also consolidate a bit the arch do_softirq overriden implementation. Only tested in x86-64 for now. Thanks. Frederic Weisbecker (3): irq

Re: [PATCH 3/3] irq: Comment on the use of inline stack for ksoftirq

On Thu, Sep 05, 2013 at 05:33:24PM +0200, Frederic Weisbecker wrote: > Ksoftirqd shouldn't need softirq stack since it's executing > in a kernel thread with a callstack that is only beginning at > this stage. > > Lets comment about that for clarity. > > Signed-of

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Thu, Sep 05, 2013 at 12:52:34PM -0700, Paul E. McKenney wrote: > There is currently no way for kernel code to determine whether it > is safe to enter an RCU read-side critical section, in other words, > whether or not RCU is paying attention to the currently running CPU. > Given the large and in

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Fri, Sep 06, 2013 at 11:33:20AM -0400, Steven Rostedt wrote: > On Fri, 6 Sep 2013 08:18:52 -0700 > "Paul E. McKenney" wrote: > > > On Fri, Sep 06, 2013 at 12:59:41PM +0200, Frederic Weisbecker wrote: > > > On Thu, Sep 05, 2013 at 12:52:34PM -0700, Paul E

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Fri, Sep 06, 2013 at 12:52:38PM -0400, Steven Rostedt wrote: > On Fri, 6 Sep 2013 18:40:18 +0200 > Frederic Weisbecker wrote: > > > > I can't use plain preempt_disable() in function tracing. > > > > > > Also, since it's a misnomer to say t

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Fri, Sep 06, 2013 at 10:41:17AM -0700, Paul E. McKenney wrote: > On Fri, Sep 06, 2013 at 10:21:28AM -0700, Eric Dumazet wrote: > > On Fri, 2013-09-06 at 08:18 -0700, Paul E. McKenney wrote: > > > > > int rcu_is_cpu_idle(void) > > > { > > > int ret; > > > > > > preempt_disable(); > > > re

[PATCH] cpufreq: Fix wrong time unit conversion

urations: cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state 2301000 0 230 0 [...] Fix this with using the proper jiffies_64_t to clock_t conversion. Reported-by: Carsten Emde Tested-by: Carsten Emde Signed-off-by: Frederic Weisbecker Cc: Carsten Emde Cc

Re: [PATCH] cpufreq: Fix wrong time unit conversion

On Sat, Sep 07, 2013 at 09:59:38PM +0200, Andreas Schwab wrote: > See also . > > Andreas. Ah I missed it. Raphael, if it is not too late, may be you could still set Andreas as the original author? Thanks. > > -- > Andreas Schwab,

Re: [PATCH tip/core/rcu 8/9] nohz_full: Add full-system-idle state machine

On Sun, Sep 08, 2013 at 12:32:50PM +0200, Yann E. MORIN wrote: > Paul, All, > > On 2013-09-07 11:57 -0700, Paul E. McKenney spake thusly: > > On Sat, Sep 07, 2013 at 11:13:48AM +0200, Yann E. MORIN wrote: > [--SNIP--] > > > I'll see if I can come up with a meaningfull construct that fixes your > >

Re: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

On Sat, Aug 31, 2013 at 10:01:17PM +0300, Sergey Senozhatsky wrote: > On (08/31/13 01:04), Frederic Weisbecker wrote: > > But stime should always be below rtime due to the calculation done by > > scale_stime() > > which roughly sums up to: > > > > stime

Re: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

On Sat, Aug 31, 2013 at 10:01:17PM +0300, Sergey Senozhatsky wrote: > On (08/31/13 01:04), Frederic Weisbecker wrote: > > But stime should always be below rtime due to the calculation done by > > scale_stime() > > which roughly sums up to: > > > > stime

Re: [PATCH] cpufreq: Fix wrong time unit conversion

On Sun, Sep 08, 2013 at 01:53:13PM +0200, Rafael J. Wysocki wrote: > On Sunday, September 08, 2013 01:49:42 PM Rafael J. Wysocki wrote: > > On Sunday, September 08, 2013 12:25:57 PM Frederic Weisbecker wrote: > > > On Sat, Sep 07, 2013 at 09:59:38PM +0200, Andreas Schwab wrote

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

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. No

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Mon, Sep 09, 2013 at 08:39:26AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2013 14:13:31 +0200 > Frederic Weisbecker wrote: > > > > > In any case the preempt_disable/enable pair there is just plain wrong as > > > Eric po

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2013 14:45:49 +0200 > Frederic Weisbecker wrote: > > > > > This just proves that the caller of rcu_is_cpu_idle() must disable > > > preemption itself for the entire time that it ne

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

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 wrote: > > > > > > > > This just proves that the c

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Mon, Sep 09, 2013 at 09:21:42AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2013 15:08:53 +0200 > Frederic Weisbecker 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 pe

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Mon, Sep 09, 2013 at 09:41:32AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2013 15:29:02 +0200 > Frederic Weisbecker wrote: > > > > No, putting that on the task_struct won't help much in this regard I think. > > Regular schedule() calls don't change that

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Mon, Sep 09, 2013 at 09:29:17AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2013 09:21:42 -0400 > Steven Rostedt 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 if CPU 1

Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?

On Mon, Sep 09, 2013 at 11:39:05AM -0400, Steven Rostedt wrote: > On Mon, 9 Sep 2013 11:20:57 -0400 > Steven Rostedt 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 sleep > >

Re: [GIT PULL] perf changes for v3.12

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

Re: [PATCH 1/3] perf callchain: Convert children list to rbtree

On Tue, Sep 10, 2013 at 12:25:54PM +0200, Ingo Molnar wrote: > > * Jiri Olsa wrote: > > > On Tue, Sep 10, 2013 at 05:24:16PM +0900, Namhyung Kim wrote: > > > From: Namhyung Kim > > > > > > Current collapse stage has a scalability problem which can be > > > reproduced easily with parallel kerne

Re: [PATCH 0/3] perf tools: Fix scalability problem on callchain merging

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 sear

Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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 th

Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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=? highlatency_c

Re: [RFC] Restrict kernel spawning of threads to a specified set of 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 kthre

Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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: > > > > > > &

Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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

Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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: > > >

Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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. > > >

Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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 erran

[PATCH 4/4] perf tools: Compare hists comm by addresses

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 Cc: Jiri Olsa Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim

[PATCH 0/4] perf tools: New comm infrastructure

May be merging 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

[PATCH 2/4] perf tools: Add time argument on comm setting

sible way to keep track of all the comms lifecycles in a thread without time informations. Signed-off-by: Frederic Weisbecker Cc: Jiri Olsa Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Stephane Eranian --- tools/perf/builtin-

[PATCH 3/4] perf tools: Add new comm infrastructure

: Frederic Weisbecker Cc: Jiri Olsa Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Stephane Eranian --- tools/perf/Makefile |2 + tools/perf/util/comm.c | 107 ++ tools/perf/util

[PATCH 1/4] perf tools: Use an accessor to read thread comm

implementation. Signed-off-by: Frederic Weisbecker Cc: Jiri Olsa Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Stephane Eranian --- tools/perf/builtin-kmem.c |2 +- tools/perf/builtin-lock.c

Re: [BUG] kernel panic during shutdown in run_timer_softirq()

On Fri, Sep 13, 2013 at 12:01:56PM +0200, Knut Petersen wrote: > Hi everybody! > > Since about July I observe occasional kernel panics happening only during > system shutdown on two systems. > > Hardware: mobos: both AOpen i915GMm-hfs mobos, cpus: Pentium-M Dothan / > Banias, mem: 2GB > Althou

Re: [PATCH 0/4] perf tools: New comm infrastructure

On Thu, Sep 12, 2013 at 10:36:58PM +0200, Ingo Molnar wrote: > > * Frederic Weisbecker wrote: > > > The way we handle hists sorted by comm is to first gather them by tid > > then in the end merge/collapse hists that end up with the same comm. > > > >

Re: [PATCH 0/4] perf tools: New comm infrastructure

On Fri, Sep 13, 2013 at 03:32:34PM +0900, Namhyung Kim wrote: > Hi Frederic, > > On Thu, 12 Sep 2013 22:29:39 +0200, Frederic Weisbecker wrote: > > The way we handle hists sorted by comm is to first gather them by tid then > > in the end merge/collapse hists that end

Re: [PATCH 4/4] perf tools: Compare hists comm by addresses

On Fri, Sep 13, 2013 at 05:07:06PM +0900, Namhyung Kim wrote: > Hi, > > On Thu, 12 Sep 2013 22:29:43 +0200, Frederic Weisbecker wrote: > > Now that comm strings are allocated only once and refcounted to be shared > > among threads, these can now be safely compared by addre

Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

On Fri, Sep 13, 2013 at 01:45:55PM +, Christoph Lameter wrote: > On Thu, 12 Sep 2013, Frederic Weisbecker wrote: > > > So yeah it's a problem in theory. Now in practice, I have yet to be > > convinced because > > this should be solved after a few iterations i

Re: [PATCH 1/8] perf callchain: Convert children list to rbtree

On Tue, Oct 08, 2013 at 11:03:16AM +0900, Namhyung Kim wrote: > On Wed, 2 Oct 2013 12:18:28 +0200, Frederic Weisbecker wrote: > > On Thu, Sep 26, 2013 at 05:58:03PM +0900, Namhyung Kim wrote: > >> From: Namhyung Kim > >> > >> Current collapse stage ha

Re: [PATCH 6/6] x86: Allow disabling HW_BREAKPOINTS and PERF_EVENTS

On Sat, Oct 05, 2013 at 07:05:52PM +0200, Andi Kleen wrote: > On Sat, Oct 05, 2013 at 09:08:06AM +0200, Ingo Molnar wrote: > > > > * Andi Kleen wrote: > > > > > From: Andi Kleen > > > > > > As suggested by Ingo. > > > > No, you haven't read my suggestion carefully enough so NAK. > > Ok I tru

Re: Thoughts on this RCU idle entry/exit patch?

On Mon, Oct 07, 2013 at 08:39:55AM -0700, Paul E. McKenney wrote: > Hello, Frederic! > > The following patch seems to me to be a good idea to better handle > task nesting. Any reason why it would be a bad thing? > > Thanx, Paul > > -

Re: [PATCH 6/6] x86: Allow disabling HW_BREAKPOINTS and PERF_EVENTS

On Tue, Oct 08, 2013 at 10:05:21PM +0200, Peter Zijlstra wrote: > On Tue, Oct 08, 2013 at 09:55:59PM +0200, Frederic Weisbecker wrote: > > 1) make breakpoints independant from perf. The drawback is that we must then > > add seperate hooks on context switch for ptrace breakpoin

Re: [PATCH 6/6] x86: Allow disabling HW_BREAKPOINTS and PERF_EVENTS

On Tue, Oct 08, 2013 at 10:05:21PM +0200, Peter Zijlstra wrote: > On Tue, Oct 08, 2013 at 09:55:59PM +0200, Frederic Weisbecker wrote: > > 1) make breakpoints independant from perf. The drawback is that we must then > > add seperate hooks on context switch for ptrace breakpoin

Re: Thoughts on this RCU idle entry/exit patch?

On Tue, Oct 08, 2013 at 02:12:18PM -0700, Paul E. McKenney wrote: > On Tue, Oct 08, 2013 at 10:34:28PM +0200, Frederic Weisbecker wrote: > > So I wonder, do we want to continue to allow this nesting? I remember that > > DYNTICK_TASK_NEST_* > > stuff is there to protects

Re: [RFC PATCH 2/6] x86: nsecs to cycles conversion

On Wed, Aug 21, 2013 at 02:26:46PM -0400, Don Zickus wrote: > On Wed, Aug 21, 2013 at 06:42:17PM +0200, Frederic Weisbecker wrote: > > hw_nmi_get_sample_period() is simply a conversion from a period > > to cycles. Lets generalize the API naming so that it can be used for > &g

Re: [RFC PATCH 6/6] timekeeping: Debug missing timekeeping updates

On Wed, Aug 21, 2013 at 10:25:57AM -0700, John Stultz wrote: > On 08/21/2013 09:42 AM, Frederic Weisbecker wrote: > > With the full dynticks feature and the tricky full system idle > > detection code that is coming soon, it becomes necessary to have > > some debug code tha

Re: [PATCH] nohz: put proper symbol in the unstable schedclock warning

On Mon, Aug 05, 2013 at 02:21:13PM +0200, Jiri Kosina wrote: > Since e12d0271 ("nohz: Warn if the machine can not perform nohz_full") > Kernel triggers a WARN() in case sched clock is marked as unstable. > > Make it output a proper Kconfig symbol (NO_HZ_FULL) when informing user > about this. >

Re: suspicious RCU usage (perf)

On Tue, Aug 27, 2013 at 02:16:29PM +0200, Peter Zijlstra wrote: > On Mon, Aug 26, 2013 at 03:03:04PM -0400, Steven Rostedt wrote: > > > Is there some path through sys_perf_open_event that might be > > > missing a capability check perhaps ? > > > > > > > That's a question for Ingo, Peter or Jiri.

Re: suspicious RCU usage (perf)

On Fri, Aug 30, 2013 at 05:59:36PM +0200, Peter Zijlstra wrote: > On Fri, Aug 30, 2013 at 05:52:43PM +0200, Frederic Weisbecker wrote: > > On Tue, Aug 27, 2013 at 02:16:29PM +0200, Peter Zijlstra wrote: > > > On Mon, Aug 26, 2013 at 03:03:04PM -0400, Steven Rostedt wrote: >

Re: suspicious RCU usage (perf)

On Tue, Aug 27, 2013 at 02:16:29PM +0200, Peter Zijlstra wrote: > On Mon, Aug 26, 2013 at 03:03:04PM -0400, Steven Rostedt wrote: > > > Is there some path through sys_perf_open_event that might be > > > missing a capability check perhaps ? > > > > > > > That's a question for Ingo, Peter or Jiri.

Re: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

On Wed, Aug 21, 2013 at 06:39:57PM +0300, Sergey Senozhatsky wrote: > On (08/20/13 17:42), Frederic Weisbecker wrote: > > On Tue, Aug 20, 2013 at 06:35:50PM +0300, Sergey Senozhatsky wrote: > > > On (08/20/13 17:15), Frederic Weisbecker wrote: > > > > On Tue, Au

Re: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

On Mon, Sep 02, 2013 at 03:28:45PM +0300, Sergey Senozhatsky wrote: > On (08/31/13 01:04), Frederic Weisbecker wrote: > > > in cputime_adjust() `stime' is greater than `rtime', so `utime = rtime - > > > stime' > > > sets wrong value. > > &g

Re: [sched next] overflowed cpu time for kernel threads in /proc/PID/stat

On Mon, Sep 02, 2013 at 03:50:34PM +0200, Stanislaw Gruszka wrote: > On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote: > > > Hope this may help. > > > I've added a silly check to make sure that `stime < rtime' > > > > > > @@

Re: [gcv v3 06/35] scheduler: Replace __get_cpu_var uses

2013/9/3 Christoph Lameter : > On Thu, 29 Aug 2013, Steven Rostedt wrote: > >> How many places use the this_cpu_*() without preemption disabled? I >> wouldn't think there's many. I never complained about another variant, >> so you need to ask those that have. The tough question for me is what >> th

Re: [PATCH 6/7] irq: Optimize softirq stack selection in irq exit

On Wed, Sep 25, 2013 at 04:04:28PM -0700, Linus Torvalds wrote: > On Wed, Sep 25, 2013 at 9:18 AM, Frederic Weisbecker > wrote: > > +#ifdef __ARCH_IRQ_EXIT_ON_IRQ_STACK > > Please don't introduce anymore of these insane ad-hoc crazy architecture > macros. > &g

[PATCH 6/8] irq: Optimize softirq stack selection in irq exit

another problem to solve. So lets adapt the irq exit's softirq stack on top of a new Kconfig symbol that can be defined when irq_exit() runs on the irq stack. That way we can spare some stack switch on irq processing and all the cache issues that come along. Signed-off-by: Frederic Wei

[PATCH 1/8] irq: Force hardirq exit's softirq processing on its own stack

e should reduce significantly the opportunities for task stack overflow dug by softirqs. Longer term solutions may involve extending the hardirq stack coverage to irq_exit(), etc... Reported-by: Benjamin Herrenschmidt Signed-off-by: Frederic Weisbecker Cc: Cc: Benjamin Herrenschmidt Cc: Paul Mack

[PATCH 0/8] softirq: Consolidation and stack overrun fix v3

06367d58f487a592de50e6e2327371c5e3b6188f ("Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc") And it can be pulled from: git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git irq/core-v4 HEAD: 0362b2ff8d67913a8ffc5d757500129ead56b007 Fr

[PATCH 4/8] irq: Improve a bit softirq debugging

t one step further and generalize that debug check to any softirq processing. Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Paul Mackerras Cc: James Hogan Cc:

[PATCH 8/8] powerpc: Tell about irq stack coverage

Now that powerpc runs irq_exit() under the irq stack, let the softirq core know about that so that we spare the needless stack switch on irq exit's softirq processing. Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixne

[PATCH 5/8] irq: Justify the various softirq stack choices

For clarity, comment the various stack choices for softirqs processing, whether we execute them from ksoftirqd or local_irq_enable() calls. Their use on irq_exit() is already commented. Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc

[PATCH 3/8] irq: Optimize call to softirq on hardirq exit

Before processing softirqs on hardirq exit, we already do the check for pending softirqs while hardirqs are guaranteed to be disabled. So we can take a shortcut and safely jump to the arch specific implementation directly. Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul

[PATCH 7/8] x86: Tell about irq stack coverage

there. x86-32 is not concerned because it only runs the irq handler on the irq stack. Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Paul Mackerras Cc: James

[PATCH 2/8] irq: Consolidate do_softirq() arch overriden implementations

switch. Signed-off-by: Frederic Weisbecker Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Paul Mackerras Cc: James Hogan Cc: James E.J. Bottomley Cc: Helge Deller Cc: Martin Schwidefsky Cc

Re: [PATCH 0/8] softirq: Consolidation and stack overrun fix v3

On Thu, Sep 26, 2013 at 09:43:38AM -0700, Linus Torvalds wrote: > On Thu, Sep 26, 2013 at 9:24 AM, Frederic Weisbecker > wrote: > > > > * Turn __ARCH_IRQ_EXIT_ON_IRQ_STACK old ad-hoc style symbol to proper > > Kconfig > > (CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK) > &

[GIT PULL] arm/context_tracking build fix

Ingo, Please pull the context_tracking/fixes branch that can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git context_tracking/fixes Thanks, Frederic --- Frederic Weisbecker (1): arm: Fix build error with context tracking calls

Re: [PATCH 0/8] softirq: Consolidation and stack overrun fix v3

On Thu, Sep 26, 2013 at 09:43:38AM -0700, Linus Torvalds wrote: > On Thu, Sep 26, 2013 at 9:24 AM, Frederic Weisbecker > wrote: > > > > * Turn __ARCH_IRQ_EXIT_ON_IRQ_STACK old ad-hoc style symbol to proper > > Kconfig > > (CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK) > &

[PATCH 2/3] nohz: Drop generic vtime obsolete dependency on CONFIG_64BIT

. McKenney Cc: Arm Linux Signed-off-by: Frederic Weisbecker --- init/Kconfig| 2 +- kernel/time/Kconfig | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 68c1a0e..841e79c 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -354,7 +354,7

[PATCH 0/3] nohz full: drop 64-bit requirement, enable ARM support v2

Hi Kevin, Your patchset was fine but I just did a second round. Namely I did the following changes: * Drop the 64 bits dependency after we settle the new dependency on HAVE_VIRT_CPU_ACCOUNTING_GEN and not before. This way we don't have a middle state that loose the dependency in the middle of

[PATCH 1/3] vtime: Add HAVE_VIRT_CPU_ACCOUNTING_GEN Kconfig

ature requested by Frederic Weisbecker. Signed-off-by: Kevin Hilman Cc: Ingo Molnar Cc: Russell King Cc: Paul E. McKenney Cc: Arm Linux Signed-off-by: Frederic Weisbecker --- arch/Kconfig| 12 init/Kconfig| 1 + kernel/time/Kconfig | 1 + 3 files changed, 14 inser

[PATCH 3/3] ARM: Kconfig: allow full nohz CPU accounting

King Cc: Paul E. McKenney Cc: Arm Linux Signed-off-by: Frederic Weisbecker --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1ad6fb6..323baf0 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -54,6 +54,7 @@ config ARM

[GIT PULL] irq fix for 3.12-rc

org/r/1380212686-25897-1-git-send-email-fweis...@gmail.com I've added Linus ack and rebased to rc3. Thanks, Frederic --- Frederic Weisbecker (1): irq: Force hardirq exit's softirq processing on its own stack kernel/softirq.c | 15 --- 1 file changed, 12 i

[GIT PULL] irq: updates for 3.13

org/r/1380212686-25897-1-git-send-email-fweis...@gmail.com with Linus and Benjamin's ack added and a rebase against rc3. It also contains the regression fix (with the same commit id) from my other pull request. Thanks, Frederic --- Frederic Weisbecker (8): irq: Force hardirq exit

Re: [GIT PULL] irq fix for 3.12-rc

On Mon, Sep 30, 2013 at 09:07:19AM -0700, Linus Torvalds wrote: > On Mon, Sep 30, 2013 at 7:55 AM, Frederic Weisbecker > wrote: > > ... > > the chances for a stack overrun as reported in powerpc for example: > > > > [ 1002.364577] do_IRQ: stack overflow: 1

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

2013/9/20 Linus Torvalds : > On Fri, Sep 20, 2013 at 9:26 AM, Frederic Weisbecker > wrote: >> >> Now just for clarity, what do we then do with inline sofirq executions: on >> local_bh_enable() >> for example, or explicit calls to do_softirq() other than irq exit?

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

On Sun, Sep 22, 2013 at 07:45:01AM +1000, Benjamin Herrenschmidt wrote: > On Sat, 2013-09-21 at 13:58 -0500, Frederic Weisbecker wrote: > > > Now certainly what needs to be fixed then is archs that don't have > > __ARCH_IRQ_EXIT_IRQS_DISABLED > > or archs th

Re: [PATCH RESEND] printk: report boot console names during cut-over

On Fri, Sep 20, 2013 at 08:34:01AM -0700, Kees Cook wrote: > This reports the names of boot consoles as they're being disabled to > help identify which is which during cut-over. Helps answer the question > "which boot console actually got activated?" once the regular console > is running, mostly wh

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

On Mon, Sep 23, 2013 at 02:40:34PM +1000, Benjamin Herrenschmidt wrote: > On Sun, 2013-09-22 at 07:45 +1000, Benjamin Herrenschmidt wrote: > > What I *can* do that would help I suppose would be to switch to the irq > > stack before irq_enter/exit which would at least mean that softirq would > > run

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

On Tue, Sep 24, 2013 at 02:42:57PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2013-09-24 at 04:44 +0200, Frederic Weisbecker wrote: > > So the safest way to fix this is to unconditionally call do_softirq() > > from irq_exit(). > > A performance penalty may come al

Re: [RFC GIT PULL] softirq: Consolidation and stack overrun fix

On Wed, Sep 25, 2013 at 06:55:47AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2013-09-24 at 15:56 +0200, Frederic Weisbecker wrote: > > On Tue, Sep 24, 2013 at 02:42:57PM +1000, Benjamin Herrenschmidt wrote: > > > On Tue, 2013-09-24 at 04:44 +0200, Frederic Weisbecker wro

Re: [PATCH v2] printk: report console names during cut-over

gt; is running, mostly when debugging boot console failures. > > Signed-off-by: Kees Cook Acked-by: Frederic Weisbecker Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH 1/7] irq: Force hardirq exit's softirq processing on its own stack

e should reduce significantly the opportunities for task stack overflow dug by softirqs. Longer term solutions may involve extending the hardirq stack coverage to irq_exit(), etc... Reported-by: Benjamin Herrenschmidt Signed-off-by: Frederic Weisbecker Cc: Cc: Benjamin Herrenschmidt Cc: Paul Mack

<    1   2   3   4   5   6   7   8   9   10   >