From: Michael Breuer <mbreuer@majjas.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Problem? intel_iommu=off; perf top shows acpi_os_read_port as extremely busy
Date: Mon, 30 Nov 2009 00:11:51 -0500 [thread overview]
Message-ID: <4B135417.1080302@majjas.com> (raw)
In-Reply-To: <20091129124731.7d0c9b45@infradead.org>
Ok - one more rather odd (to me) data point...
I started playing around with various settings, and traced the calls to
acpi_os_read_port.
To summarize:
With intel_iommu=off, I see a large percentage of calls to
acpi_os_read_port resulting from user apps (portsentry is #1).
With intel_iommu=on, NONE of trace points to any user apps - all derive
from the idle loop.
To make things more interesting, when I enable intel_iommu and disable
vt-d in bios, the system performs much better (20% improvement in
glxgears, for example), perf top looks like this:
------------------------------------------------------------------------------
PerfTop: 4863 irqs/sec kernel:62.7% [100000 cycles], (all, 8 CPUs)
------------------------------------------------------------------------------
samples pcnt kernel function
_______ _____ _______________
2213.00 - 5.5% : acpi_idle_enter_bm
2001.00 - 5.0% : acpi_os_read_port
1544.00 - 3.9% : _spin_lock_irqsave
1075.00 - 2.7% : ioread32
928.00 - 2.3% : find_busiest_group
851.00 - 2.1% : _spin_unlock_irqrestore
823.00 - 2.1% : hpet_next_event
810.00 - 2.0% : tg_shares_up
655.00 - 1.6% : fget_light
641.00 - 1.6% : schedule
639.00 - 1.6% : tick_nohz_stop_sched_tick
638.00 - 1.6% : sub_preempt_count
634.00 - 1.6% : add_preempt_count
548.00 - 1.4% : do_sys_poll
446.00 - 1.1% : trace_hardirqs_off
And additionally, one recurring boot warning I've seen since I first
booted this box has disappeared - first boot message of IRQ16 disabled.
I'm thinking that bad VT-D bios is causing trouble even when intel_iommu
is disabled.
On 11/29/2009 03:47 PM, Arjan van de Ven wrote:
> On Sat, 28 Nov 2009 13:10:21 -0500
> Michael Breuer<mbreuer@majjas.com> wrote:
>
>
>> Ok - my only question then is why things appear so different with
>> intel_iommu enabled.
>>
> something else is even more expensive then :0
>
>
>
prev parent reply other threads:[~2009-11-30 5:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-28 0:20 Problem? intel_iommu=off; perf top shows acpi_os_read_port as extremely busy Michael Breuer
2009-11-28 7:18 ` Ingo Molnar
2009-11-28 15:27 ` Peter Zijlstra
2009-11-28 15:47 ` Michael Breuer
2009-11-28 17:45 ` Arjan van de Ven
2009-11-28 18:10 ` Michael Breuer
2009-11-29 20:47 ` Arjan van de Ven
2009-11-30 5:11 ` Michael Breuer [this message]
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=4B135417.1080302@majjas.com \
--to=mbreuer@majjas.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=arjan@infradead.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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.