Re: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-09-07 Thread Peter Zijlstra
On Sat, Sep 06, 2014 at 07:12:26PM +0200, Frederic Weisbecker wrote: > On Sat, Sep 06, 2014 at 05:45:56PM +0200, Peter Zijlstra wrote: > > On Sat, Sep 06, 2014 at 03:35:15PM +0200, Frederic Weisbecker wrote: > > > You have a script that does that arch/*/include/asm/Kbuild edit for you > > > right?

Re: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-09-06 Thread Frederic Weisbecker
On Sat, Sep 06, 2014 at 05:45:56PM +0200, Peter Zijlstra wrote: > On Sat, Sep 06, 2014 at 03:35:15PM +0200, Frederic Weisbecker wrote: > > You have a script that does that arch/*/include/asm/Kbuild edit for you > > right? > > Is this something in scripts/ ? > > See commit b119fa61d440 ("locking/m

Re: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-09-06 Thread Peter Zijlstra
On Sat, Sep 06, 2014 at 03:35:15PM +0200, Frederic Weisbecker wrote: > You have a script that does that arch/*/include/asm/Kbuild edit for you right? > Is this something in scripts/ ? See commit b119fa61d440 ("locking/mcs: Order the header files in Kbuild of each architecture in alphabetical order

Re: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-09-06 Thread Frederic Weisbecker
On Thu, Sep 04, 2014 at 08:11:37AM +0200, Peter Zijlstra wrote: > On Thu, Aug 21, 2014 at 04:52:51PM +0200, Frederic Weisbecker wrote: > > diff --git a/kernel/irq_work.c b/kernel/irq_work.c > > index e6bcbe7..17bd203 100644 > > --- a/kernel/irq_work.c > > +++ b/kernel/irq_work.c > > @@ -22,6 +22,7

Re: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-09-05 Thread Frederic Weisbecker
On Thu, Sep 04, 2014 at 05:40:20PM +0200, Peter Zijlstra wrote: > On Thu, Sep 04, 2014 at 03:33:40PM +0200, Frederic Weisbecker wrote: > > > Why not something like the below; then it becomes a compile time matter. > > > > Problem is that some archs only have that information at runtime. > > See x8

Re: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-09-04 Thread Peter Zijlstra
On Thu, Sep 04, 2014 at 03:33:40PM +0200, Frederic Weisbecker wrote: > > Why not something like the below; then it becomes a compile time matter. > > Problem is that some archs only have that information at runtime. > See x86 for example which tests cpu_has_apic. So the other archs can still bene

Re: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-09-04 Thread Frederic Weisbecker
On Thu, Sep 04, 2014 at 08:11:37AM +0200, Peter Zijlstra wrote: > On Thu, Aug 21, 2014 at 04:52:51PM +0200, Frederic Weisbecker wrote: > > diff --git a/kernel/irq_work.c b/kernel/irq_work.c > > index e6bcbe7..17bd203 100644 > > --- a/kernel/irq_work.c > > +++ b/kernel/irq_work.c > > @@ -22,6 +22,7

Re: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-09-03 Thread Peter Zijlstra
On Thu, Aug 21, 2014 at 04:52:51PM +0200, Frederic Weisbecker wrote: > diff --git a/kernel/irq_work.c b/kernel/irq_work.c > index e6bcbe7..17bd203 100644 > --- a/kernel/irq_work.c > +++ b/kernel/irq_work.c > @@ -22,6 +22,7 @@ > > static DEFINE_PER_CPU(struct llist_head, raised_list); > static D

[RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt

2014-08-21 Thread Frederic Weisbecker
The nohz full kick, which restarts the tick after some new state depend on it, can't be called from any place given the operation it does on timers. If it is called from the scheduler or timers code, chances are that we run into a deadlock. This is why we run the nohz full kick from an irq work. T