From: Adrian Bunk <bunk@stusta.de>
To: kus Kusche Klaus <kus@keba.com>
Cc: Lee Revell <rlrevell@joe-job.com>,
linux-kernel@vger.kernel.org, john.ronciak@intel.com,
ganesh.venkatesan@intel.com, jesse.brandeburg@intel.com,
netdev@vger.kernel.org
Subject: Re: My vote against eepro* removal
Date: Thu, 19 Jan 2006 17:20:57 +0100 [thread overview]
Message-ID: <20060119162056.GP19398@stusta.de> (raw)
In-Reply-To: <AAD6DA242BC63C488511C611BD51F367323322@MAILIT.keba.co.at>
On Thu, Jan 19, 2006 at 11:26:51AM +0100, kus Kusche Klaus wrote:
> > From: Lee Revell
> > On Thu, 2006-01-19 at 08:19 +0100, kus Kusche Klaus wrote:
> > > Last time I tested (around 2.6.12), eepro100 worked much better
> > > in -rt kernels w.r.t. latencies than e100:
> > >
> > > e100 caused a periodic latency of about 500 microseconds
> > > exactly every 2 seconds, no matter what the load on the interface
> > > was (i.e. even on an idle interface).
> > >
> > > eepro100 did not show any latencies that long, it worked much
> > > smoother w.r.t. latencies.
> > >
> > > Of course I would prefer to have e100 fixed over keeping eepro100
> > > around forever, but the last time I checked, it still wasn't fixed.
> >
> > Please provide latency traces to illustrate the problematic code path.
>
> It's not a "latency": As far as I can tell, interrupts or preemption
> are not disabled, the latency tracer doesn't show anything.
>
> I just noticed that low-pri rt processes did not get scheduled for
> about 500 microseconds when e100 was active (even if the net was
> idle), and that there were no such breaks with eepro100.
>
> I didn't analyze it in detail at that time, I believed that the e100
> interrupt handler thread was running every 2 seconds for 500
> microseconds, because the interrupt count of eth0 incremented every
> 2 seconds, exactly when my rt processes paused.
>
> This would be bad: That irq thread is at rt prio 47 on my system,
> above many importent things.
>
> However, I checked more closely now, and found out that only a small
> portion of the 500 microseconds is spent in the irq thread. Most of
> it is spent in the timer thread, at rt prio 1, so the whole thing
> is a much smaller problem than I originally believed.
>
> Must be the function e100_watchdog.
>...
Is this with 2.6.12 or 2.6.16-rc1?
If it's the former, please check whether the problem is still presnt in
the latter.
If it's the latter, I'm sure the e100 developers (Cc'ed) are interested
in your problem.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2006-01-19 16:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-19 10:26 My vote against eepro* removal kus Kusche Klaus
2006-01-19 16:20 ` Adrian Bunk [this message]
2006-01-19 17:16 ` John Ronciak
2006-01-19 19:09 ` Steven Rostedt
2006-01-19 22:57 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2006-01-24 7:38 kus Kusche Klaus
2006-01-23 11:01 kus Kusche Klaus
2006-01-23 20:23 ` Jesse Brandeburg
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: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=20060119162056.GP19398@stusta.de \
--to=bunk@stusta.de \
--cc=ganesh.venkatesan@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=kus@keba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rlrevell@joe-job.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.