irq_work
in [Kernel]
|
From: Peter Zijlstra on 24 Jun 2010 03:30 On Thu, 2010-06-24 at 15:04 +0800, Huang Ying wrote: > Yes. NMI is there from 8259 age. But do we really care about such systems? > That is possible. But in NO_HZ system, we have no tick to rely on. Of course you have, you can delay the NO_HZ state when there's pending callbacks, that's all of 1 line. > soft_irq is better here, because it will be triggered for any interrupt. Well, you can do the callbacks from irq_exit() as well, that's no problem. -- 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 24 Jun 2010 03:30 On Thu, 2010-06-24 at 15:19 +0800, Peter Zijlstra wrote: > On Thu, 2010-06-24 at 15:04 +0800, Huang Ying wrote: > > > Yes. NMI is there from 8259 age. > > But do we really care about such systems? > > > That is possible. But in NO_HZ system, we have no tick to rely on. > > Of course you have, you can delay the NO_HZ state when there's pending > callbacks, that's all of 1 line. > > > soft_irq is better here, because it will be triggered for any interrupt. > > Well, you can do the callbacks from irq_exit() as well, that's no > problem. I think it is not a good idea to add overhead in such a hot path if the overhead can be avoided. 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: Peter Zijlstra on 24 Jun 2010 03:40 On Thu, 2010-06-24 at 15:27 +0800, Huang Ying wrote: > On Thu, 2010-06-24 at 15:19 +0800, Peter Zijlstra wrote: > > On Thu, 2010-06-24 at 15:04 +0800, Huang Ying wrote: > > > > > Yes. NMI is there from 8259 age. > > > > But do we really care about such systems? > > > > > That is possible. But in NO_HZ system, we have no tick to rely on. > > > > Of course you have, you can delay the NO_HZ state when there's pending > > callbacks, that's all of 1 line. > > > > > soft_irq is better here, because it will be triggered for any interrupt. > > > > Well, you can do the callbacks from irq_exit() as well, that's no > > problem. > > I think it is not a good idea to add overhead in such a hot path if the > overhead can be avoided. True, but I really don't like the softirq thing, and I really don't care about !APIC machines, I probably couldn't buy one if I wanted to and its not like we have good MCE support for them now, so who cares. -- 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 24 Jun 2010 06:30 > True, but I really don't like the softirq thing, and I really don't care > about !APIC machines, I probably couldn't buy one if I wanted to and its > not like we have good MCE support for them now, so who cares. In theory you can run a machine with good MCE support in non APIC single CPU mode. It wouldn't make much sense, but you could do it. Anyways, I don't think we need a lot of effort to handle this case, but it would be better to not explicitely break it either. That's why the timer fallback in the original code was fine, this basically never happens and even if there is a 5s delay from tickless that's fine. -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: Peter Zijlstra on 24 Jun 2010 06:40
On Thu, 2010-06-24 at 12:27 +0200, Andi Kleen wrote: > > True, but I really don't like the softirq thing, and I really don't care > > about !APIC machines, I probably couldn't buy one if I wanted to and its > > not like we have good MCE support for them now, so who cares. > > In theory you can run a machine with good MCE support in non APIC single > CPU mode. It wouldn't make much sense, but you could do it. > > Anyways, I don't think we need a lot of effort to handle this case, > but it would be better to not explicitely break it either. > > That's why the timer fallback in the original code was fine, this > basically never happens and even if there is a 5s delay from tickless > that's fine. Right, in that case I would very much prefer the simpler thing I proposed over all this softirq stuff, we can have the tick process the callbacks for really broken hardware (perf_events doesn't care since without a lapic there's no pmi anyway). -- 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/ |