From: Dave Sperry <dave_sperry@ieee.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Poor UDP performance using 2.6.21-rc5-rt5
Date: Mon, 02 Apr 2007 04:17:25 -0400 [thread overview]
Message-ID: <4610BC15.5030800@ieee.org> (raw)
In-Reply-To: <20070402072111.GA21356@elte.hu>
Ingo Molnar wrote:
> * Dave Sperry <dave_sperry@ieee.org> wrote:
>
>> I have a dual core Opteron machine that exhibits poor UDP performance
>> (RT consumes more than 2X cpu) with the 2.6.21-rc5-rt5 as compared to
>> 2.6.21-rc5. Top shows the IRQ handler consuming a lot of CPU.
>
> update: even with acpi_pm clocksource on vanilla i can reproduce similar
> overhead using netperf.
>
> Ingo
>
Hi Ingo
I checked the clock source and in both the vanilla and rt cases and they
were both acpi_pm
Here's the oprofile for my vanilla case:
CPU: AMD64 processors, speed 2211.37 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
unit mask of 0x00 (No unit mask) count 100000
samples % image name app name
symbol name
36264 18.2763 forcedeth.ko forcedeth
nv_nic_irq_optimized
25602 12.9029 vmlinux vmlinux
spurious_interrupt
10067 5.0736 forcedeth.ko forcedeth
nv_start_xmit_optimized
8671 4.3700 vmlinux vmlinux
unregister_kprobe
8270 4.1679 vmlinux vmlinux
ctrl_dumpfamily
8042 4.0530 vmlinux vmlinux
expand_files
5064 2.5521 vmlinux vmlinux kfree
4365 2.1999 libc-2.5.so libc-2.5.so
__sendto_nocancel
4067 2.0497 vmlinux vmlinux
unix_bind
4010 2.0210 vmlinux vmlinux bad_gs
3929 1.9801 vmlinux vmlinux
__alloc_skb
3859 1.9449 vmlinux vmlinux
stack_segment
3107 1.5659 vmlinux vmlinux
__find_get_block
2816 1.4192 vmlinux vmlinux
vfs_create
2611 1.3159 vmlinux vmlinux
ide_end_drive_cmd
2604 1.3124 vmlinux vmlinux
ide_end_request
2560 1.2902 vmlinux vmlinux
find_get_page
2458 1.2388 vmlinux vmlinux
hrtimer_run_queues
2456 1.2378 vmlinux vmlinux
get_wchan
2403 1.2111 forcedeth.ko forcedeth
nv_tx_done_optimized
2231 1.1244 vmlinux vmlinux
do_sys_poll
Any thoughts?
Thanks
Dave
next prev parent reply other threads:[~2007-04-02 8:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-01 19:15 Poor UDP performance using 2.6.21-rc5-rt5 Dave Sperry
2007-04-01 20:07 ` Nivedita Singhvi
2007-04-01 22:00 ` Dave Sperry
2007-04-02 5:55 ` Ingo Molnar
2007-04-02 6:30 ` Ingo Molnar
2007-04-02 7:21 ` Ingo Molnar
2007-04-02 8:17 ` Dave Sperry [this message]
2007-04-02 9:37 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2007-04-02 14:09 dave_sperry@ieee.org
2007-04-02 14:23 ` Ingo Molnar
2007-04-02 17:17 dave_sperry@ieee.org
2007-04-02 17:50 dave_sperry@ieee.org
2007-04-02 19:04 ` Ingo Molnar
2007-04-03 0:09 ` David Sperry
2007-04-03 6:43 ` Ingo Molnar
2007-04-03 8:51 ` Ingo Molnar
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=4610BC15.5030800@ieee.org \
--to=dave_sperry@ieee.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
/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.