From: Tony Lindgren <tony@atomide.com>
To: Koen Kooi <k.kooi@student.utwente.nl>
Cc: "Woodruff, Richard" <r-woodruff2@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment
Date: Tue, 5 Aug 2008 15:14:36 +0300 [thread overview]
Message-ID: <20080805121435.GZ7193@atomide.com> (raw)
In-Reply-To: <C2CB0AC6-3065-469C-AAAF-F78F3DEFFFB8@student.utwente.nl>
* 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
>>
>
next prev parent reply other threads:[~2008-08-05 12:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-19 12:54 FW: [PATCH] suppress needless timer reprogramming {tick-sched.c} - test/comment Woodruff, Richard
2008-06-19 22:01 ` Felipe Balbi
2008-06-19 22:06 ` Woodruff, Richard
2008-06-20 7:45 ` Felipe Balbi
2008-06-20 12:42 ` Woodruff, Richard
2008-08-05 12:09 ` Koen Kooi
2008-08-05 12:14 ` Tony Lindgren [this message]
2008-08-05 12:21 ` Koen Kooi
2008-08-05 12:22 ` Woodruff, Richard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080805121435.GZ7193@atomide.com \
--to=tony@atomide.com \
--cc=k.kooi@student.utwente.nl \
--cc=linux-omap@vger.kernel.org \
--cc=r-woodruff2@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.