All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Andi Kleen <ak@suse.de>
Cc: discuss@x86-64.org, Muli Ben-Yehuda <mulix@mulix.org>,
	Jon Mason <jdmason@us.ibm.com>, Muli Ben-Yehuda <muli@il.ibm.com>,
	Linux-Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [discuss] Re: [PATCH 2/4] x86-64: Calgary IOMMU - move valid_dma_direction into the callers
Date: Fri, 26 May 2006 04:55:22 -0400	[thread overview]
Message-ID: <4476C27A.7040707@garzik.org> (raw)
In-Reply-To: <200605260957.02163.ak@suse.de>

Andi Kleen wrote:
> On Thursday 25 May 2006 11:58, Jeff Garzik wrote:
>> Muli Ben-Yehuda wrote:
>>> On Thu, May 25, 2006 at 12:35:07AM -0400, Jeff Garzik wrote:
>>>> Jon Mason wrote:
>>>>> >From Andi Kleen's comments on the original Calgary patch, move
>>>>> valid_dma_direction into the calling functions.
>>>>>
>>>>> Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
>>>>> Signed-off-by: Jon Mason <jdmason@us.ibm.com>
>>>> Even though BUG_ON() includes unlikely(), this introduces additional 
>>>> tests in very hot paths.
>>> Are they really very hot? I mean if you're calling the DMA API, you're
>>> about to frob the hardware or have already frobbed it - does this
>>> check really matter?
>> When you are adding a check that will _never_ be hit in production, to 
>> the _hottest_ paths in the kernel, you can be assured it matters...
> 
> pci_dma_* shouldn't be that hot. Or at least IO usually has so much
> overhead that some more bugging shouldn't matter.

I respectfully disagree with that logic.  If its a key hot path -- which 
it is, every modern network or disk I/O runs through these paths -- then 
it deserves at least _some_ consideration before adding more CPU cycles.


> On the other hand if the problem of passing wrong parameters here
> isn't common I would be ok with dropping them.

As the author noted, it was only used in early platform bring-up.  And 
simply reviewing the patch... it is clear that screwing up the 
parameters would cause massive, noticeable problems immediately -- such 
as on EM64T with swiotlb.

	Jeff



  reply	other threads:[~2006-05-26  8:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-25  3:35 [PATCH 2/4] x86-64: Calgary IOMMU - move valid_dma_direction into the callers Jon Mason
2006-05-25  4:35 ` Jeff Garzik
2006-05-25  9:42   ` Muli Ben-Yehuda
2006-05-25  9:58     ` Jeff Garzik
2006-05-26  7:57       ` [discuss] " Andi Kleen
2006-05-26  8:55         ` Jeff Garzik [this message]
2006-05-26  9:35           ` Andi Kleen

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=4476C27A.7040707@garzik.org \
    --to=jeff@garzik.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=discuss@x86-64.org \
    --cc=jdmason@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=muli@il.ibm.com \
    --cc=mulix@mulix.org \
    /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.