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: Tejun Heo on 17 Jun 2010 07:30 On 06/17/2010 01:12 PM, Thomas Gleixner wrote: >> Hmmm.... oh, I see. Wouldn't it be much better to use moving avg of >> IRQ durations instead of letting the driver specify it? Drivers are >> most likely to just hard code it and It's never gonna be accurate. > > Right, but that's probably more accurate than the core code heuristics > ever will be. Eh, not really. For ATA at least, there will be three different classes of devices. SSDs, hard drives and optical devices and if we get running avg w/ fairly large stability part, the numbers wouldn't be too far off and there's no reliable way for the driver to tell which type of device is on the other side of the cable. So, I think running avg would work much better. 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: Alan Cox on 17 Jun 2010 07:50 On Thu, 17 Jun 2010 13:23:27 +0200 Tejun Heo <tj(a)kernel.org> wrote: > On 06/17/2010 01:12 PM, Thomas Gleixner wrote: > >> Hmmm.... oh, I see. Wouldn't it be much better to use moving avg of > >> IRQ durations instead of letting the driver specify it? Drivers are > >> most likely to just hard code it and It's never gonna be accurate. > > > > Right, but that's probably more accurate than the core code heuristics > > ever will be. > > Eh, not really. For ATA at least, there will be three different > classes of devices. SSDs, hard drives and optical devices At least four: It may also be battery backed RAM. Alan -- 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 17 Jun 2010 12:00 On 06/17/2010 01:43 PM, Alan Cox wrote: > On Thu, 17 Jun 2010 13:23:27 +0200 > Tejun Heo <tj(a)kernel.org> wrote: > >> On 06/17/2010 01:12 PM, Thomas Gleixner wrote: >>>> Hmmm.... oh, I see. Wouldn't it be much better to use moving avg of >>>> IRQ durations instead of letting the driver specify it? Drivers are >>>> most likely to just hard code it and It's never gonna be accurate. >>> >>> Right, but that's probably more accurate than the core code heuristics >>> ever will be. >> >> Eh, not really. For ATA at least, there will be three different >> classes of devices. SSDs, hard drives and optical devices > > At least four: It may also be battery backed RAM. Yeah, right, there are those crazy devices too but I think they would fall in a single tick any way. At any rate, let's say I have those numbers, how would I feed it into c-state selection? 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 17 Jun 2010 12:10 On Thu, 17 Jun 2010 17:54:48 +0200 Tejun Heo <tj(a)kernel.org> wrote: > Crazy devices too but I think they would > fall in a single tick any way. not sure what ticks have to do with anything but ok ;) > At any rate, let's say I have those > numbers, how would I feed it into c-state selection? if we have this, we need to put a bit of glue in the backend that tracks (per cpu I suppose) the shortest expected interrupt, which the C state code then queries. (and in that regard, it does not matter if shortest expected is computed via heuristic on a per irq basis, or passed in). mapping an irq to a cpu is not a 100% science (since interrupts can move in theory), but just assuming that the irq will happen on the same CPU it happened last time is more than good enough. -- 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 17 Jun 2010 12:50
On 06/17/2010 06:02 PM, Arjan van de Ven wrote: > On Thu, 17 Jun 2010 17:54:48 +0200 > Tejun Heo <tj(a)kernel.org> wrote: > >> Crazy devices too but I think they would >> fall in a single tick any way. > > not sure what ticks have to do with anything but ok ;) Eh... right, I was thinking about something else. IRQ expect code originally had a tick based duration estimator to determine poll interval which I ripped out later for simpler stepped adjustments. c-state would need higher frequency timing measurements than jiffies. >> At any rate, let's say I have those >> numbers, how would I feed it into c-state selection? > > if we have this, we need to put a bit of glue in the backend that > tracks (per cpu I suppose) the shortest expected interrupt, which > the C state code then queries. > (and in that regard, it does not matter if shortest expected is > computed via heuristic on a per irq basis, or passed in). > > mapping an irq to a cpu is not a 100% science (since interrupts can > move in theory), but just assuming that the irq will happen on the same > CPU it happened last time is more than good enough. 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? 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/ |