Re: [RFC][PATCH] irq_work -v2

[Andi Kleen <andi@firstfloor.org>]

On Sat, Jun 26, 2010 at 10:36:45AM +0200, Peter Zijlstra wrote:
> On Sat, 2010-06-26 at 00:29 +0200, Andi Kleen wrote:
> 
> > Yes it would be good to separate that, because I doubt other users
> > will require similar hacks.
> 
> You're such a constructive critic..

Well I'm only adapting to your tone (FWIW I thought your original
description of Ying's patches was bordering to unfair, not quoting
the words back to you). I find it also always interesting when
people who always dish out with full hands are quite sensitive themselves...

But yes we can agree to not use such tone, if that's a mutual agreement.

> I would think every NMI user would need them since NMI can interrupt at
> any time, and if you have a limited number of irq_work structs (like 1
> per cpu) you'll end up with wanting to enqueue an already enqueued one
> at some point.

You could as well drop the excessive event. In fact it surprises me that you 
don't simply do that in perf. The state should be in the PMU registers 
anyways, so you'll pick it up from there (and if you get NMIs as quickly that 
you cannot process them you have to eventually throttle by dropping anyways)

With the reuse methology you end up with the same problem anyways, is
just shifts it slightly.

For fatal NMIs it's more like: if the error is fatal then the NMI handler
will stop and if it's non fatal it can be dropped on overload.
For overload situations there needs to be a dropping mechanism, spinning
is not ok because you don't know if the current owner isn't on your
own CPU.

Some of the other errors cannot drop, but these need other mechanisms
anyways.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.