irq: implement IRQ expecting
in [Kernel]
|
Prev: [PATCHv4.1 07/13] USB: gadget: g_ether: updated INF file
Next: [PATCH 1/1] kbuild: fix LOCALVERSION handling to match description
From: Andi Kleen on 19 Jun 2010 05:10 > IIUC, it's not to help or optimize polling itself. It just gives us a > way to estimate when the next interrupt would be so that power can be > optimized for non polling cases. Shouldn't the idle governour estimate this already? BTW I looked at something like this for networking. There was one case where a network benchmark was impacted by deep sleep states while processing packets. But in the end it turned out to be mostly a broken BIOS that gave wrong parameters to the idle governour. -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: Tejun Heo on 19 Jun 2010 05:10 Hello, On 06/19/2010 11:00 AM, Andi Kleen wrote: >> IIUC, it's not to help or optimize polling itself. It just gives us a >> way to estimate when the next interrupt would be so that power can be >> optimized for non polling cases. > > Shouldn't the idle governour estimate this already? I'm not an expert on the subject. According to Arjan, One of the hard cases right now that the C state code has is that it needs to predict the future. While it has a ton of heuristics, including some is there IO oustanding" ones, libata is a really good case: libata will know generally that within one seek time (5 msec on rotating rust, much less on floating electrons) there'll be an interrupt (give or take, but this is what we can do heuristics for on a per irq level). So it's a good suggestion of what the future will be like, MUCH better than any hint we have right now... all we have right now is some history, and when the next timer is.... So, it seems like it would help. Thanks. -- tejun -- 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: Arjan van de Ven on 19 Jun 2010 11:00 On Sat, 19 Jun 2010 11:00:31 +0200 Andi Kleen <andi(a)firstfloor.org> wrote: > > IIUC, it's not to help or optimize polling itself. It just gives > > us a way to estimate when the next interrupt would be so that power > > can be optimized for non polling cases. > > Shouldn't the idle governour estimate this already? we have a set of heuristics in the idle governor to try to predict the future. For patterns that are regular in some shape of form we can do this. Here we have the opportunity to get real good information.. we KNOW now an interrupt is coming, and we can even estimate how long it'll be... Even for the first few after a long time, before a pattern emerges. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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 19 Jun 2010 15:50 > Here we have the opportunity to get real good information.. we KNOW > now an interrupt is coming, and we can even estimate how long it'll > be... Even for the first few after a long time, before a pattern > emerges. Ok but I thought the driver would just fill in a single number likely. Is that really that good information? Alternatively each driver would need to implement some dynamic estimation algorithm, but that would be just mostly equivalent to having it all in the idle governour? -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: Arjan van de Ven on 19 Jun 2010 16:10
On Sat, 19 Jun 2010 21:49:37 +0200 Andi Kleen <andi(a)firstfloor.org> wrote: > > Here we have the opportunity to get real good information.. we KNOW > > now an interrupt is coming, and we can even estimate how long it'll > > be... Even for the first few after a long time, before a pattern > > emerges. > > Ok but I thought the driver would just fill in a single number > likely. Is that really that good information? Tejun suggested tracking this per handler, I'm assuming that instead of the driver passed number > > Alternatively each driver would need to implement some dynamic > estimation algorithm, but that would be just mostly equivalent > to having it all in the idle governour? that's the whole point... let the irq layer track this stuff, and inform the governor. the governor does not know irqs are expected.. with tejun's change, the irq layer at least will. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/ |