From: Jesse Brandeburg <jesse.brandeburg@intel.com>
To: kus Kusche Klaus <kus@keba.com>
Cc: Lee Revell <rlrevell@joe-job.com>,
Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
Adrian Bunk <bunk@stusta.de>,
linux-kernel@vger.kernel.org, "Ronciak,
John" <john.ronciak@intel.com>,
"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
netdev@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>
Subject: RE: My vote against eepro* removal
Date: Mon, 23 Jan 2006 12:23:26 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0601231202530.3847@lindenhurst-2.jf.intel.com> (raw)
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323329@MAILIT.keba.co.at>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3497 bytes --]
On Mon, 23 Jan 2006, kus Kusche Klaus wrote:
> From: John Ronciak
> > Can we try a couple of things? 1) just comment out all the check for
> > link code in the e100 driver and give that a try and 2) just comment
> > out the update stats call and see if that works. These seem to be the
> > differences and we need to know which one is causing the problem.
>
> First of all, I am still unable to get any traces of this in the
> latency tracer. Moreover, as I told before, removing parts of the
> watchdog usually made my eth0 nonfunctional (which is bad - this
> is an embedded system with ssh access).
>
> Hence, I explicitely instrumented the watchdog function with tsc.
> Output of the timings is done by a background thread, so the
> timings should not increase the runtime of the watchdog.
>
> Here are my results:
>
> If the watchdog doesn't get interrupted, preempted, or whatever,
> it spends 340 us in its body:
> * 303 us in the mii code
> * 36 us in the following code up to e100_adjust_adaptive_ifs
> * 1 us in the remaining code (I think my chip doesn't need any
> of those chip-specific fixups)
>
> The 303 us in the mii code are divided in the following way:
> * 101 us in mii_ethtool_gset
> * 135 us in the whole if
> * 67 us in mii_check_link
>
> This is with the udelay(2) instead of udelay(20) hack applied.
> With udelay(20), the mii times are 128 + 170 + 85 us,
> i.e. 383 us instead of 303 us, or >= 420 us for the whole watchdog.
>
> As the RTC runs with 8192 Hz during my tests, the watchdog is hit
> by 2-3 interrupts, which adds another 75 - 110 us to its total
> execution time, i.e. the time it blocks other rtprio 1 threads.
Thank you very much for that detailed analysis! okay, so calls to mii.c
take too long, but those depend on mmio_read in e100 to do the work, so
this patch attempts to minimize the latency.
This patch is against linus-2.6.git, I compile and ssh/ping tested it.
Would you be willing to send your instrumentation patches? I could then
test any fixes easier.
e100: attempt a shorter delay for mdio reads
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Simply reorder our write/read sequence for mdio reads to minimize latency
as well as delay a shorter interval for each loop.
---
drivers/net/e100.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -891,23 +891,25 @@ static u16 mdio_ctrl(struct nic *nic, u3
* procedure it should be done under lock.
*/
spin_lock_irqsave(&nic->mdio_lock, flags);
- for (i = 100; i; --i) {
+ for (i = 1000; i; --i) {
if (readl(&nic->csr->mdi_ctrl) & mdi_ready)
break;
- udelay(20);
+ udelay(2);
}
if (unlikely(!i)) {
- printk("e100.mdio_ctrl(%s) won't go Ready\n",
+ DPRINTK(PROBE, ERR, "e100.mdio_ctrl(%s) won't go Ready\n",
nic->netdev->name );
spin_unlock_irqrestore(&nic->mdio_lock, flags);
return 0; /* No way to indicate timeout error */
}
writel((reg << 16) | (addr << 21) | dir | data, &nic->csr->mdi_ctrl);
- for (i = 0; i < 100; i++) {
- udelay(20);
+ /* to avoid latency, read to flush the write, then delay, and only
+ * delay 2us per loop, manual says read should complete in < 64us */
+ for (i = 0; i < 1000; i++) {
if ((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
break;
+ udelay(2);
}
spin_unlock_irqrestore(&nic->mdio_lock, flags);
DPRINTK(HW, DEBUG,
next prev parent reply other threads:[~2006-01-23 20:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-23 11:01 My vote against eepro* removal kus Kusche Klaus
2006-01-23 20:23 ` Jesse Brandeburg [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-01-24 7:38 kus Kusche Klaus
2006-01-20 11:27 kus Kusche Klaus
2006-01-20 10:51 kus Kusche Klaus
2006-01-20 11:05 ` Evgeniy Polyakov
2006-01-20 10:19 kus Kusche Klaus
2006-01-20 11:02 ` Evgeniy Polyakov
2006-01-21 0:45 ` Lee Revell
2006-01-20 9:37 kus Kusche Klaus
2006-01-20 9:55 ` Evgeniy Polyakov
2006-01-21 0:40 ` Lee Revell
2006-01-21 1:19 ` John Ronciak
2006-01-21 1:30 ` Lee Revell
2006-01-21 2:01 ` John Ronciak
2006-01-21 3:56 ` Lee Revell
2006-01-19 10:26 kus Kusche Klaus
2006-01-19 16:20 ` Adrian Bunk
2006-01-19 17:16 ` John Ronciak
2006-01-19 19:09 ` Steven Rostedt
2006-01-19 22:57 ` Steven Rostedt
2006-01-19 10:08 kus Kusche Klaus
2006-01-19 7:19 kus Kusche Klaus
2006-01-19 7:24 ` Lee Revell
2006-01-19 7:42 ` Arjan van de Ven
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=Pine.LNX.4.64.0601231202530.3847@lindenhurst-2.jf.intel.com \
--to=jesse.brandeburg@intel.com \
--cc=bunk@stusta.de \
--cc=john.ronciak@intel.com \
--cc=johnpol@2ka.mipt.ru \
--cc=kus@keba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rlrevell@joe-job.com \
--cc=rostedt@goodmis.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).