All of lore.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 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.