linux-kernel - Re: Problem? intel_iommu=off; perf top shows acpi_os_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-id: <4B135417.1080302@majjas.com>
Date:	Mon, 30 Nov 2009 00:11:51 -0500
From:	Michael Breuer <mbreuer@...jas.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Len Brown <lenb@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Problem? intel_iommu=off; perf top shows acpi_os_read_port as
 extremely busy

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@...jas.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
>
>
>    

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/