From: Jiri Slaby on
On 06/13/2010 05:31 PM, Tejun Heo wrote:
> --- a/kernel/irq/spurious.c
> +++ b/kernel/irq/spurious.c
....

> @@ -25,9 +26,43 @@ enum {
> /* IRQ polling common parameters */
> IRQ_POLL_SLOW_INTV = 3 * HZ, /* not too slow for ppl, slow enough for machine */
> IRQ_POLL_INTV = HZ / 100, /* from the good ol' 100HZ tick */
> + IRQ_POLL_QUICK_INTV = HZ / 1000, /* pretty quick but not too taxing */
>
> IRQ_POLL_SLOW_SLACK = HZ,
> IRQ_POLL_SLACK = HZ / 1000, /* 10% slack */
> + IRQ_POLL_QUICK_SLACK = HZ / 10000, /* 10% slack */

Hi. These are zeros on most systems (assuming distros set HZ=100 and
250), what is their purpose then?

regards,
--
js
--
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
On 06/14/2010 11:43 AM, Tejun Heo wrote:
> Hello,
>
> On 06/14/2010 11:21 AM, Jiri Slaby wrote:
>> On 06/13/2010 05:31 PM, Tejun Heo wrote:
>>> --- a/kernel/irq/spurious.c
>>> +++ b/kernel/irq/spurious.c
>> ...
>>
>>> @@ -25,9 +26,43 @@ enum {
>>> /* IRQ polling common parameters */
>>> IRQ_POLL_SLOW_INTV = 3 * HZ, /* not too slow for ppl, slow enough for machine */
>>> IRQ_POLL_INTV = HZ / 100, /* from the good ol' 100HZ tick */
>>> + IRQ_POLL_QUICK_INTV = HZ / 1000, /* pretty quick but not too taxing */
>>>
>>> IRQ_POLL_SLOW_SLACK = HZ,
>>> IRQ_POLL_SLACK = HZ / 1000, /* 10% slack */
>>> + IRQ_POLL_QUICK_SLACK = HZ / 10000, /* 10% slack */
>>
>> Hi. These are zeros on most systems (assuming distros set HZ=100 and
>> 250), what is their purpose then?
>
> On every tick and no slack. :-)

Hmmm... but yeah, it would be better to make IRQ_POLL_SLACK HZ / 250
so that we at least have one tick slack on 250HZ configs which are
pretty common these days.

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
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...


--
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
Hello, Arjan.

On 06/17/2010 05:48 AM, Arjan van de Ven wrote:
> 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...

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.

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

On Thu, 17 Jun 2010, Tejun Heo wrote:

> Hello, Arjan.
>
> On 06/17/2010 05:48 AM, Arjan van de Ven wrote:
> > 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...
>
> 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.

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/