From: Peter Zijlstra on
On Fri, 2010-06-18 at 23:16 +0800, huang ying wrote:
>
> soft_irq is a delayed mechanism for IRQ,

No its not.

> a self interrupt can be a
> delayed mechanism for NMI. If we can make soft_irq NMI-safe,

No you can't.

> we can
> use soft_irq as a backup of self interrupt (for systems without APIC
> and maybe for other architectures).

Whatever would you want to do that for.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: huang ying on
On Fri, Jun 18, 2010 at 11:31 PM, Peter Zijlstra <peterz(a)infradead.org> wrote:
> On Fri, 2010-06-18 at 23:16 +0800, huang ying wrote:
>>
>> soft_irq is a delayed mechanism for IRQ,
>
> No its not.

Why? What do you think soft_irq is for?

>>  a self interrupt can be a
>> delayed mechanism for NMI. If we can make soft_irq NMI-safe,
>
> No you can't.
>
>> we can
>> use soft_irq as a backup of self interrupt (for systems without APIC
>> and maybe for other architectures).
>
> Whatever would you want to do that for.

Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on
> > we can
> > use soft_irq as a backup of self interrupt (for systems without APIC
> > and maybe for other architectures).
>
> Whatever would you want to do that for.

The idea is that the work would be done latest on the next
timer interrupt as a fallback if APIC is not available.

That's what mce does already and it's probably approbiate
for most other users too.

-Andi

--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on

( Ugh: what's this new fad of you not quoting the name of the person who
wrote a mail? It makes multi-level quotes utterly unreadable as it's not
clear who wrote what. You should also respect others by quoting their names. )

* Andi Kleen <andi(a)firstfloor.org> wrote:

> > > we can use soft_irq as a backup of self interrupt (for systems without
> > > APIC and maybe for other architectures).
> >
> > Whatever would you want to do that for.
>
> The idea is that the work would be done latest on the next timer interrupt
> as a fallback if APIC is not available.

Abusing the timer irq for that is an exceedingly ugly and unacceptable design,
as machine check events have nothing to do with timers. (That approach is also
buggy because it inserts an arbitrary delay - which could be rather long on
nohz.)

This kind of messy, ad-hoc piggybacking only creates unmaintainable code in
the long run.

> That's what mce does already and it's probably approbiate for most other
> users too.

Hell no, the unfortunate and unclean practices of the MCE code must not be
propagated elsewhere.

The proper, generic approach would be to enable softirq notifications (on x86)
from NMI contexts as well (it's actually possible without overhead), and to
extend user return notifiers with the logical next step: nmi return notifiers.
If presented in such a form then those could use softirqs for atomic callbacks
and per cpu kthreads for sleepable callbacks, etc.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: huang ying on
On Sat, Jun 19, 2010 at 6:53 PM, Ingo Molnar <mingo(a)elte.hu> wrote:
> The proper, generic approach would be to enable softirq notifications (on x86)
> from NMI contexts as well (it's actually possible without overhead),

Yes. I will do that. And I think self interrupt can be used as the
short-cut for soft_irq if available. The next soft_irq may be too late
if there is too few interrupts.

> and to
> extend user return notifiers with the logical next step: nmi return notifiers.
> If presented in such a form then those could use softirqs for atomic callbacks
> and per cpu kthreads for sleepable callbacks, etc.

NMI return notifiers fired in soft_irq?

Best Regards,
Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/