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: Arjan van de Ven on 18 Jun 2010 02:30 On Thu, 17 Jun 2010 18:47:19 +0200 Tejun Heo <tj(a)kernel.org> wrote: > > Hmmm... the thing is that there will be many cases which won't fit > irq_expect() model (why irq_watch() exists in the first place) and for > the time being libata is the only one providing that data. Would the > data still be useful to determine which c-state to use? yes absolutely. 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.... -- 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: Tejun Heo on 18 Jun 2010 05:30 Hello, On 06/18/2010 08:26 AM, Arjan van de Ven wrote: > On Thu, 17 Jun 2010 18:47:19 +0200 > Tejun Heo <tj(a)kernel.org> wrote: > >> >> Hmmm... the thing is that there will be many cases which won't fit >> irq_expect() model (why irq_watch() exists in the first place) and for >> the time being libata is the only one providing that data. Would the >> data still be useful to determine which c-state to use? > > yes absolutely. 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.... Cool, good to know. It shouldn't be difficult to at all to add. Once the whole thing gets generally agreed on, I'll work on that. Thomas, Ingo, through which tree should these patches routed through? Shall I set up a separate branch? 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: Thomas Gleixner on 18 Jun 2010 05:50 On Fri, 18 Jun 2010, Tejun Heo wrote: > Hello, > > On 06/18/2010 08:26 AM, Arjan van de Ven wrote: > > On Thu, 17 Jun 2010 18:47:19 +0200 > > Tejun Heo <tj(a)kernel.org> wrote: > > > >> > >> Hmmm... the thing is that there will be many cases which won't fit > >> irq_expect() model (why irq_watch() exists in the first place) and for > >> the time being libata is the only one providing that data. Would the > >> data still be useful to determine which c-state to use? > > > > yes absolutely. 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.... > > Cool, good to know. It shouldn't be difficult to at all to add. Once > the whole thing gets generally agreed on, I'll work on that. > > Thomas, Ingo, through which tree should these patches routed through? I'm going to pull that into tip/genirq I guess Thanks, tglx -- 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 04:40 Arjan van de Ven <arjan(a)infradead.org> writes: > On Sun, 13 Jun 2010 17:31:35 +0200 > Tejun Heo <tj(a)kernel.org> wrote: >> + */ >> +void expect_irq(struct irq_expect *exp) > > > I would like to suggest an (optional) argument to this with a duration > within which to expect an interrupt.... > > that way in the backend we can plumb this also into the idle handler > for C state selection... I'm not sure it's really that useful to power optimize the lost interrupts polling case. It's just a last resort fallback anyways and will be always less power efficient because there will be unnecessary polls. -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 04:50
Hello, On 06/19/2010 10:35 AM, Andi Kleen wrote: >> I would like to suggest an (optional) argument to this with a duration >> within which to expect an interrupt.... >> >> that way in the backend we can plumb this also into the idle handler >> for C state selection... > > I'm not sure it's really that useful to power optimize > the lost interrupts polling case. It's just a last resort > fallback anyways and will be always less power efficient > because there will be unnecessary polls. 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. 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/ |