FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Woodruff, Richard]

Hi,

I'll resend this to the omap list.  I had originally sent it with some pictures but I guess they were too big for the lists.  Individual should have got them.

If anyone has the time this is a good to test with.  If you have dynamic tick enabled it can double performance of high rate interrupt things like MUSB.

If anyone wants I'll re-send larger trace pictures individually.


> From: Woodruff, Richard, Monday, June 16, 2008 7:06 PM
>
> It simply does a check to see if the about to be reprogrammed 1 shot
> already is the last event programmed in the hardware.  If it is it skips
> calling the hardware.
>
> In my device I get many interrupts from a high speed USB device in a
> very short period of time.  The system spends a lot of time
> reprogramming the hardware timer which is in a slower timing domain as
> compared to the CPU.  This results in the CPU spending a huge amount of
> time waiting for the timer posting to be done.  All of this
> reprogramming is useless as the wake up time has not changed.
>
> As measured using ETM trace this drops my reprogramming penalty from
> almost 60% CPU load down to 15% during high interrupt rate.  If you like
> I can send traces to show this.

Attached are some results on OMAP-ARM from USB-OTG:

As host:

root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
[root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 32.51
user 0.02
sys 1.05
[root@OMAP3EVM /]# umount /mnt/
[root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
[root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 17.92
user 0.05
sys 1.57

As Client:

Attached are some visuals as of client doing gadget zero tests.  Pictures clearly show before a domination by timer reprogram and after not.

Regards,
Richard W.


diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index b854a89..ff6b967 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -254,6 +254,17 @@ void tick_nohz_stop_sched_tick(void)
        /* Schedule the tick, if we are at least one jiffie off */
        if ((long)delta_jiffies >= 1) {

+               /*
+               * calculate the expiry time for the next timer wheel
+               * timer
+               */
+               expires = ktime_add_ns(last_update, tick_period.tv64 *
+                                  delta_jiffies);
+
+               /* Skip reprogram of event if its not changed */
+               if(ts->tick_stopped && ktime_equal(expires, dev->next_event))
+                       goto out2;
+
                if (delta_jiffies > 1)
                        cpu_set(cpu, nohz_cpu_mask);
                /*
@@ -304,12 +315,7 @@ void tick_nohz_stop_sched_tick(void)
                        goto out;
                }

-               /*
-                * calculate the expiry time for the next timer wheel
-                * timer
-                */
-               expires = ktime_add_ns(last_update, tick_period.tv64 *
-                                      delta_jiffies);
+               /* Mark expiries */
                ts->idle_expires = expires;

                if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
@@ -328,6 +334,7 @@ void tick_nohz_stop_sched_tick(void)
                tick_do_update_jiffies64(ktime_get());
                cpu_clear(cpu, nohz_cpu_mask);
        }
+out2:
        raise_softirq_irqoff(TIMER_SOFTIRQ);
 out:
        ts->next_jiffies = next_jiffies;

Re: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Felipe Balbi]

On Thu, 19 Jun 2008 07:54:19 -0500, "Woodruff, Richard"
<r-woodruff2@ti.com> wrote:
> Hi,
> 
> I'll resend this to the omap list.  I had originally sent it with some
> pictures but I guess they were too big for the lists.  Individual should
> have got them.
> 
> If anyone has the time this is a good to test with.  If you have dynamic
> tick enabled it can double performance of high rate interrupt things like
> MUSB.
> 
> If anyone wants I'll re-send larger trace pictures individually.

care to send it to my nokia mail?
felipe 'dot' balbi 'at' nokia 'dot' com

I'll take a shot at this patch after summer holidays.


ps: I'm keeping the rest of the mail below so it' ll be
easier for getting the patch at work :-p








> 
> 
>> From: Woodruff, Richard, Monday, June 16, 2008 7:06 PM
>>
>> It simply does a check to see if the about to be reprogrammed 1 shot
>> already is the last event programmed in the hardware.  If it is it skips
>> calling the hardware.
>>
>> In my device I get many interrupts from a high speed USB device in a
>> very short period of time.  The system spends a lot of time
>> reprogramming the hardware timer which is in a slower timing domain as
>> compared to the CPU.  This results in the CPU spending a huge amount of
>> time waiting for the timer posting to be done.  All of this
>> reprogramming is useless as the wake up time has not changed.
>>
>> As measured using ETM trace this drops my reprogramming penalty from
>> almost 60% CPU load down to 15% during high interrupt rate.  If you like
>> I can send traces to show this.
> 
> Attached are some results on OMAP-ARM from USB-OTG:
> 
> As host:
> 
> root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
> [root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
> real 32.51
> user 0.02
> sys 1.05
> [root@OMAP3EVM /]# umount /mnt/
> [root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
> [root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
> real 17.92
> user 0.05
> sys 1.57
> 
> As Client:
> 
> Attached are some visuals as of client doing gadget zero tests.  Pictures
> clearly show before a domination by timer reprogram and after not.
> 
> Regards,
> Richard W.
> 
> 
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index b854a89..ff6b967 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -254,6 +254,17 @@ void tick_nohz_stop_sched_tick(void)
>         /* Schedule the tick, if we are at least one jiffie off */
>         if ((long)delta_jiffies >= 1) {
> 
> +               /*
> +               * calculate the expiry time for the next timer wheel
> +               * timer
> +               */
> +               expires = ktime_add_ns(last_update, tick_period.tv64 *
> +                                  delta_jiffies);
> +
> +               /* Skip reprogram of event if its not changed */
> +               if(ts->tick_stopped && ktime_equal(expires,
> dev->next_event))
> +                       goto out2;
> +
>                 if (delta_jiffies > 1)
>                         cpu_set(cpu, nohz_cpu_mask);
>                 /*
> @@ -304,12 +315,7 @@ void tick_nohz_stop_sched_tick(void)
>                         goto out;
>                 }
> 
> -               /*
> -                * calculate the expiry time for the next timer wheel
> -                * timer
> -                */
> -               expires = ktime_add_ns(last_update, tick_period.tv64 *
> -                                      delta_jiffies);
> +               /* Mark expiries */
>                 ts->idle_expires = expires;
> 
>                 if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
> @@ -328,6 +334,7 @@ void tick_nohz_stop_sched_tick(void)
>                 tick_do_update_jiffies64(ktime_get());
>                 cpu_clear(cpu, nohz_cpu_mask);
>         }
> +out2:
>         raise_softirq_irqoff(TIMER_SOFTIRQ);
>  out:
>         ts->next_jiffies = next_jiffies;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

RE: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Woodruff, Richard]

> > If anyone wants I'll re-send larger trace pictures individually.
>
> care to send it to my nokia mail?
> felipe 'dot' balbi 'at' nokia 'dot' com

Ok.

> I'll take a shot at this patch after summer holidays.

Ok.  I did catch Thomas G. on IRC and he indicated it seemed fine and would try later after fixing some bugs.

Perhaps more exciting would be to make sure x86 didn't care.  My ARM targets only work better.

Regards,
Richard W.

RE: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Felipe Balbi]

On Thu, 19 Jun 2008 17:06:11 -0500, "Woodruff, Richard"
<r-woodruff2@ti.com> wrote:

>> care to send it to my nokia mail?
>> felipe 'dot' balbi 'at' nokia 'dot' com
> 
> Ok.

Thanks for sending them :-)

> Ok.  I did catch Thomas G. on IRC and he indicated it seemed fine and
> would try later after fixing some bugs.

That's great :-)

> Perhaps more exciting would be to make sure x86 didn't care.  My ARM
> targets only work better.

better sending to lkml, then?

I'm pretty sure at least ehci will be positively affected. We could
be getting around 400mbps throughput with ehci (and musb) but last
time I tried I got something around 150mbps.

That was a good catch Richard :-)

-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

RE: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Woodruff, Richard]

> > Perhaps more exciting would be to make sure x86 didn't care.  My ARM
> > targets only work better.
>
> better sending to lkml, then?

Actually I did that first when my confidence was high. No obvious interest.  The signal to noise ratio is pretty high. David B. did comment.  As its important for OMAP I'll make sure to continue to follow up.

> I'm pretty sure at least ehci will be positively affected. We could
> be getting around 400mbps throughput with ehci (and musb) but last
> time I tried I got something around 150mbps.

EHCI probably will gain.

The last recent timer fix I pushed which Tony helped with also was caught the same kind of effect at OMAP.  It showed up as MP3 (with low interrupt load) taking much more MHz then it should.  But that was not as a dramatic impact as the high interrupt load cases.

As you can see ETM is really cool ;)

Regards,
Richard W.

Re: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 3987 bytes --]


Op 19 jun 2008, om 14:54 heeft Woodruff, Richard het volgende  
geschreven:

> Hi,
>
> I'll resend this to the omap list.  I had originally sent it with  
> some pictures but I guess they were too big for the lists.   
> Individual should have got them.
>
> If anyone has the time this is a good to test with.  If you have  
> dynamic tick enabled it can double performance of high rate  
> interrupt things like MUSB.

This patch has been working for me quite well these last few week, any  
chance it can to into git?

regards,

Koen


> If anyone wants I'll re-send larger trace pictures individually.
>
>
>> From: Woodruff, Richard, Monday, June 16, 2008 7:06 PM
>>
>> It simply does a check to see if the about to be reprogrammed 1 shot
>> already is the last event programmed in the hardware.  If it is it  
>> skips
>> calling the hardware.
>>
>> In my device I get many interrupts from a high speed USB device in a
>> very short period of time.  The system spends a lot of time
>> reprogramming the hardware timer which is in a slower timing domain  
>> as
>> compared to the CPU.  This results in the CPU spending a huge  
>> amount of
>> time waiting for the timer posting to be done.  All of this
>> reprogramming is useless as the wake up time has not changed.
>>
>> As measured using ETM trace this drops my reprogramming penalty from
>> almost 60% CPU load down to 15% during high interrupt rate.  If you  
>> like
>> I can send traces to show this.
>
> Attached are some results on OMAP-ARM from USB-OTG:
>
> As host:
>
> root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
> [root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
> real 32.51
> user 0.02
> sys 1.05
> [root@OMAP3EVM /]# umount /mnt/
> [root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
> [root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
> real 17.92
> user 0.05
> sys 1.57
>
> As Client:
>
> Attached are some visuals as of client doing gadget zero tests.   
> Pictures clearly show before a domination by timer reprogram and  
> after not.
>
> Regards,
> Richard W.
>
>
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index b854a89..ff6b967 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -254,6 +254,17 @@ void tick_nohz_stop_sched_tick(void)
>        /* Schedule the tick, if we are at least one jiffie off */
>        if ((long)delta_jiffies >= 1) {
>
> +               /*
> +               * calculate the expiry time for the next timer wheel
> +               * timer
> +               */
> +               expires = ktime_add_ns(last_update, tick_period.tv64 *
> +                                  delta_jiffies);
> +
> +               /* Skip reprogram of event if its not changed */
> +               if(ts->tick_stopped && ktime_equal(expires, dev- 
> >next_event))
> +                       goto out2;
> +
>                if (delta_jiffies > 1)
>                        cpu_set(cpu, nohz_cpu_mask);
>                /*
> @@ -304,12 +315,7 @@ void tick_nohz_stop_sched_tick(void)
>                        goto out;
>                }
>
> -               /*
> -                * calculate the expiry time for the next timer wheel
> -                * timer
> -                */
> -               expires = ktime_add_ns(last_update, tick_period.tv64 *
> -                                      delta_jiffies);
> +               /* Mark expiries */
>                ts->idle_expires = expires;
>
>                if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
> @@ -328,6 +334,7 @@ void tick_nohz_stop_sched_tick(void)
>                tick_do_update_jiffies64(ktime_get());
>                cpu_clear(cpu, nohz_cpu_mask);
>        }
> +out2:
>        raise_softirq_irqoff(TIMER_SOFTIRQ);
> out:
>        ts->next_jiffies = next_jiffies;
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Tony Lindgren]

* Koen Kooi <k.kooi@student.utwente.nl> [080805 15:11]:
>
> Op 19 jun 2008, om 14:54 heeft Woodruff, Richard het volgende  
> geschreven:
>
>> Hi,
>>
>> I'll resend this to the omap list.  I had originally sent it with some 
>> pictures but I guess they were too big for the lists.  Individual 
>> should have got them.
>>
>> If anyone has the time this is a good to test with.  If you have  
>> dynamic tick enabled it can double performance of high rate interrupt 
>> things like MUSB.
>
> This patch has been working for me quite well these last few week, any  
> chance it can to into git?

This needs to go in via LKML, I think Thomas Gleixner is looking into it.

Tony


>
> regards,
>
> Koen
>
>
>> If anyone wants I'll re-send larger trace pictures individually.
>>
>>
>>> From: Woodruff, Richard, Monday, June 16, 2008 7:06 PM
>>>
>>> It simply does a check to see if the about to be reprogrammed 1 shot
>>> already is the last event programmed in the hardware.  If it is it  
>>> skips
>>> calling the hardware.
>>>
>>> In my device I get many interrupts from a high speed USB device in a
>>> very short period of time.  The system spends a lot of time
>>> reprogramming the hardware timer which is in a slower timing domain  
>>> as
>>> compared to the CPU.  This results in the CPU spending a huge amount 
>>> of
>>> time waiting for the timer posting to be done.  All of this
>>> reprogramming is useless as the wake up time has not changed.
>>>
>>> As measured using ETM trace this drops my reprogramming penalty from
>>> almost 60% CPU load down to 15% during high interrupt rate.  If you  
>>> like
>>> I can send traces to show this.
>>
>> Attached are some results on OMAP-ARM from USB-OTG:
>>
>> As host:
>>
>> root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
>> [root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
>> real 32.51
>> user 0.02
>> sys 1.05
>> [root@OMAP3EVM /]# umount /mnt/
>> [root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
>> [root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
>> real 17.92
>> user 0.05
>> sys 1.57
>>
>> As Client:
>>
>> Attached are some visuals as of client doing gadget zero tests.   
>> Pictures clearly show before a domination by timer reprogram and after 
>> not.
>>
>> Regards,
>> Richard W.
>>
>>
>> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
>> index b854a89..ff6b967 100644
>> --- a/kernel/time/tick-sched.c
>> +++ b/kernel/time/tick-sched.c
>> @@ -254,6 +254,17 @@ void tick_nohz_stop_sched_tick(void)
>>        /* Schedule the tick, if we are at least one jiffie off */
>>        if ((long)delta_jiffies >= 1) {
>>
>> +               /*
>> +               * calculate the expiry time for the next timer wheel
>> +               * timer
>> +               */
>> +               expires = ktime_add_ns(last_update, tick_period.tv64 *
>> +                                  delta_jiffies);
>> +
>> +               /* Skip reprogram of event if its not changed */
>> +               if(ts->tick_stopped && ktime_equal(expires, dev- 
>> >next_event))
>> +                       goto out2;
>> +
>>                if (delta_jiffies > 1)
>>                        cpu_set(cpu, nohz_cpu_mask);
>>                /*
>> @@ -304,12 +315,7 @@ void tick_nohz_stop_sched_tick(void)
>>                        goto out;
>>                }
>>
>> -               /*
>> -                * calculate the expiry time for the next timer wheel
>> -                * timer
>> -                */
>> -               expires = ktime_add_ns(last_update, tick_period.tv64 *
>> -                                      delta_jiffies);
>> +               /* Mark expiries */
>>                ts->idle_expires = expires;
>>
>>                if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
>> @@ -328,6 +334,7 @@ void tick_nohz_stop_sched_tick(void)
>>                tick_do_update_jiffies64(ktime_get());
>>                cpu_clear(cpu, nohz_cpu_mask);
>>        }
>> +out2:
>>        raise_softirq_irqoff(TIMER_SOFTIRQ);
>> out:
>>        ts->next_jiffies = next_jiffies;
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" 
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

Re: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 4850 bytes --]


Op 5 aug 2008, om 14:14 heeft Tony Lindgren het volgende geschreven:

> * Koen Kooi <k.kooi@student.utwente.nl> [080805 15:11]:
>>
>> Op 19 jun 2008, om 14:54 heeft Woodruff, Richard het volgende
>> geschreven:
>>
>>> Hi,
>>>
>>> I'll resend this to the omap list.  I had originally sent it with  
>>> some
>>> pictures but I guess they were too big for the lists.  Individual
>>> should have got them.
>>>
>>> If anyone has the time this is a good to test with.  If you have
>>> dynamic tick enabled it can double performance of high rate  
>>> interrupt
>>> things like MUSB.
>>
>> This patch has been working for me quite well these last few week,  
>> any
>> chance it can to into git?
>
> This needs to go in via LKML, I think Thomas Gleixner is looking  
> into it.

Great! It seems that the bulk of the patches OE applies to the  
beagleboard kernel are on their way into upstream :)

regards,

Koen


>
>
> Tony
>
>
>>
>> regards,
>>
>> Koen
>>
>>
>>> If anyone wants I'll re-send larger trace pictures individually.
>>>
>>>
>>>> From: Woodruff, Richard, Monday, June 16, 2008 7:06 PM
>>>>
>>>> It simply does a check to see if the about to be reprogrammed 1  
>>>> shot
>>>> already is the last event programmed in the hardware.  If it is it
>>>> skips
>>>> calling the hardware.
>>>>
>>>> In my device I get many interrupts from a high speed USB device  
>>>> in a
>>>> very short period of time.  The system spends a lot of time
>>>> reprogramming the hardware timer which is in a slower timing domain
>>>> as
>>>> compared to the CPU.  This results in the CPU spending a huge  
>>>> amount
>>>> of
>>>> time waiting for the timer posting to be done.  All of this
>>>> reprogramming is useless as the wake up time has not changed.
>>>>
>>>> As measured using ETM trace this drops my reprogramming penalty  
>>>> from
>>>> almost 60% CPU load down to 15% during high interrupt rate.  If you
>>>> like
>>>> I can send traces to show this.
>>>
>>> Attached are some results on OMAP-ARM from USB-OTG:
>>>
>>> As host:
>>>
>>> root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
>>> [root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
>>> real 32.51
>>> user 0.02
>>> sys 1.05
>>> [root@OMAP3EVM /]# umount /mnt/
>>> [root@OMAP3EVM /]# mount -t vfat /dev/sda1 /mnt/
>>> [root@OMAP3EVM /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
>>> real 17.92
>>> user 0.05
>>> sys 1.57
>>>
>>> As Client:
>>>
>>> Attached are some visuals as of client doing gadget zero tests.
>>> Pictures clearly show before a domination by timer reprogram and  
>>> after
>>> not.
>>>
>>> Regards,
>>> Richard W.
>>>
>>>
>>> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
>>> index b854a89..ff6b967 100644
>>> --- a/kernel/time/tick-sched.c
>>> +++ b/kernel/time/tick-sched.c
>>> @@ -254,6 +254,17 @@ void tick_nohz_stop_sched_tick(void)
>>>       /* Schedule the tick, if we are at least one jiffie off */
>>>       if ((long)delta_jiffies >= 1) {
>>>
>>> +               /*
>>> +               * calculate the expiry time for the next timer wheel
>>> +               * timer
>>> +               */
>>> +               expires = ktime_add_ns(last_update,  
>>> tick_period.tv64 *
>>> +                                  delta_jiffies);
>>> +
>>> +               /* Skip reprogram of event if its not changed */
>>> +               if(ts->tick_stopped && ktime_equal(expires, dev-
>>>> next_event))
>>> +                       goto out2;
>>> +
>>>               if (delta_jiffies > 1)
>>>                       cpu_set(cpu, nohz_cpu_mask);
>>>               /*
>>> @@ -304,12 +315,7 @@ void tick_nohz_stop_sched_tick(void)
>>>                       goto out;
>>>               }
>>>
>>> -               /*
>>> -                * calculate the expiry time for the next timer  
>>> wheel
>>> -                * timer
>>> -                */
>>> -               expires = ktime_add_ns(last_update,  
>>> tick_period.tv64 *
>>> -                                      delta_jiffies);
>>> +               /* Mark expiries */
>>>               ts->idle_expires = expires;
>>>
>>>               if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
>>> @@ -328,6 +334,7 @@ void tick_nohz_stop_sched_tick(void)
>>>               tick_do_update_jiffies64(ktime_get());
>>>               cpu_clear(cpu, nohz_cpu_mask);
>>>       }
>>> +out2:
>>>       raise_softirq_irqoff(TIMER_SOFTIRQ);
>>> out:
>>>       ts->next_jiffies = next_jiffies;
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux- 
>>> omap"
>>> in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

RE: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment

[Woodruff, Richard]

> This needs to go in via LKML, I think Thomas Gleixner is looking into
> it.

* Today it is in Andrew Morton's tree.

* Thomas has been in copy and Andrew has ack'ed it.  So far Thomas hasn't had much interest.  I haven't bugged him since Andrew picked it up as I guess it will flow in from his tree.

I have locally one more change to this code which also makes a good performance difference dealing with the soft-irq task.  I wanted more testing before pushing that.

Regards,
Richard W.