RE: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
Op 5 aug 2008, om 14:14 heeft Tony Lindgren het volgende geschreven:
* Koen Kooi <[EMAIL PROTECTED]> [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:
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 32.51
user 0.02
sys 1.05
[EMAIL PROTECTED] /]# umount /mnt/
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
PGP.sig
Description: This is a digitally signed message part
Re: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
* Koen Kooi <[EMAIL PROTECTED]> [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:
>>
>> [EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
>> [EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
>> real 32.51
>> user 0.02
>> sys 1.05
>> [EMAIL PROTECTED] /]# umount /mnt/
>> [EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
>> [EMAIL PROTECTED] /]# 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 [EMAIL PROTECTED]
>> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
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:
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 32.51
user 0.02
sys 1.05
[EMAIL PROTECTED] /]# umount /mnt/
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
PGP.sig
Description: This is a digitally signed message part
RE: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
> > 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: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
On Thu, 19 Jun 2008 17:06:11 -0500, "Woodruff, Richard" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
> > 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.
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
On Thu, 19 Jun 2008 07:54:19 -0500, "Woodruff, Richard"
<[EMAIL PROTECTED]> 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:
>
> [EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
> [EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
> real 32.51
> user 0.02
> sys 1.05
> [EMAIL PROTECTED] /]# umount /mnt/
> [EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
> [EMAIL PROTECTED] /]# 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 [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Felipe Balbi
http://felipebalbi.com
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
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:
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# time -p cp /mnt/OE.mtn.bz2 /dev/null
real 32.51
user 0.02
sys 1.05
[EMAIL PROTECTED] /]# umount /mnt/
[EMAIL PROTECTED] /]# mount -t vfat /dev/sda1 /mnt/
[EMAIL PROTECTED] /]# 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
