public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
>
>
>    


      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox