Re: libata/sata_nv latency on NVIDIA CK804 [was Re: AMD64 X2 lost ticks on PM timer]

From: Jeff Garzik <jeff@garzik.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Lee Revell <rlrevell@joe-job.com>,
	"Bill Rugolsky Jr." <brugolsky@telemetry-investments.com>,
	Andi Kleen <ak@suse.de>, Jason Baron <jbaron@redhat.com>,
	linux-kernel@vger.kernel.org, john stultz <johnstul@us.ibm.com>
Subject: Re: libata/sata_nv latency on NVIDIA CK804 [was Re: AMD64 X2 lost ticks on PM timer]
Date: Wed, 15 Mar 2006 17:22:35 -0500	[thread overview]
Message-ID: <441893AB.1070300@garzik.org> (raw)
In-Reply-To: <20060315215848.GB18241@elte.hu>

Ingo Molnar wrote:
> in this particular case there's only very simple (and non-IO) 
> instructions in that codepath (no loops either), except for 
> ata_bmdma_status() which does IO ops: so i agree with you that the most 
> likely candidate for the delay is the readb() or the inb() in 
> ata_bdma_status().
> 
> I'm wondering which one of the two. inb()s are known to be horrible on 
> some systems - but i've never seen them take 16 milliseconds. If it's 
> the inb(), then that could also involve SMM mode and IO 

ata_bmdma_status() is just a single IO read, and even 1ms is highly 
improbable.

I'd look elsewhere.  There are a ton of udelay() calls in the legacy PCI 
IDE BMDMA code paths (sata_nv uses these), so I'm not surprised there is 
latency in general, in a libata+sata_nv configuration.  Status checks 
for example (ata_busy_wait in libata.h) are basically

	while (ioreadX() != condition)
		udelay(10)

That delay is mainly a "don't pound too hard on the hardware" delay.  If 
the hardware is really slow completing a command after signalling 
completion, you'll potentially wait up to 1000*10 us in some cases.  And 
there are other delays, such as the per-command ndelay() plus ioread().

Welcome to the wonderful world of IDE.

	Jeff