From: Esben Nielsen <simlo@phys.au.dk>
To: Nish Aravamudan <nish.aravamudan@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Gautam H Thaker <gthaker@atl.lmco.com>,
linux-kernel@vger.kernel.org
Subject: Re: ~5x greater CPU load for a networked application when using 2.6.15-rt15-smp vs. 2.6.12-1.1390_FC4
Date: Thu, 23 Feb 2006 23:07:37 +0100 (MET) [thread overview]
Message-ID: <Pine.OSF.4.05.10602232238560.19969-100000@da410> (raw)
In-Reply-To: <29495f1d0602231314m6ea84f85wc2792c1b6b7c4715@mail.gmail.com>
When PREEMPT_RT is settled down I propose that many of the irq-handlers
are moved back to "raw" irq context. I am sure many of them are so short
that it wont increase latency. It is always a balance between needed
latency and performance. Basicly, the rule is that all irq handlers
running for less that the lower required latency and rare enough not
to take a significant part of the CPU load, should run in irq context.
Now the kernel hacker doesn't know for how long various irq handlers run
on a specific piece of hardware and which latencies the application need.
Therefore it has to be a config option per driver. The driver locks
ofcourse also need to be change from rt_lock to raw_spin_lock depending on
that option. Thus a macro framework for making the right choices of lock
type fitting the choosen irq-handler context it, is needed.
For the issue here, I am pretty sure changing the ethernet driver from
running in task context to raw irq context will improve the performance.
What you need to meassure as well, is how it influences latencies. There
is a good change you will see you can't meassure any difference because so
little work is actually done in irq context, must of the work is done
by the DMA controller.
Esben
On Thu, 23 Feb 2006, Nish Aravamudan wrote:
> On 2/23/06, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Nish Aravamudan <nish.aravamudan@gmail.com> wrote:
> >
> > > Would it make more sense to compare 2.6.15 and 2.6.15-rt17, as opposed
> > > to 2.6.12-1.1390_FC4 and 2.6.15-rt17? Seems like the closer the two
> > > kernels are, the easier it will be to isolate the differences.
> >
> > good point. I'd expect there to be similar 'top' output, but still worth
> > doing for comparable results.
>
> I'd also expect little difference (hopefully) -- although there's
> always an off-chance something big changed somewhere and the problem
> was fixed in mainline. Just makes the comparison clearer.
>
> Thanks,
> Nish
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2006-02-23 22:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-23 19:55 Gautam H Thaker
2006-02-23 20:15 ` Benjamin LaHaise
2006-02-23 20:58 ` Ingo Molnar
2006-02-23 21:06 ` Nish Aravamudan
2006-02-23 21:08 ` Ingo Molnar
2006-02-23 21:14 ` Nish Aravamudan
2006-02-23 22:07 ` Esben Nielsen [this message]
2006-02-24 8:03 ` Jan Engelhardt
2006-02-24 12:11 ` Andrew Morton
2006-02-24 20:06 ` Gautam H Thaker
2006-02-24 20:31 ` Andrew Morton
2006-02-24 20:44 ` Gautam H Thaker
2006-02-24 16:52 ` Theodore Ts'o
2006-02-24 19:25 ` Gautam H Thaker
2006-02-28 19:27 ` Matt Mackall
2006-02-28 22:19 ` Gautam H Thaker
2006-07-11 18:08 Jonathan Walsh
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.OSF.4.05.10602232238560.19969-100000@da410 \
--to=simlo@phys.au.dk \
--cc=gthaker@atl.lmco.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nish.aravamudan@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®