All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: joerg.roedel@amd.com, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, iommu@lists.linux-foundation.org,
	dwmw2@infradead.org, muli@il.ibm.com, amit.shah@qumranet.com,
	mingo@redhat.com
Subject: Re: [PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops
Date: Sun, 28 Sep 2008 20:44:24 +0200	[thread overview]
Message-ID: <20080928184424.GA26563@8bytes.org> (raw)
In-Reply-To: <20080928231211X.fujita.tomonori@lab.ntt.co.jp>

On Sun, Sep 28, 2008 at 11:21:23PM +0900, FUJITA Tomonori wrote:
> > +struct dma_mapping_ops *find_dma_ops_for_device(struct device *dev)
> > +{
> > +	int i;
> > +	unsigned long flags;
> > +	struct dma_mapping_ops *entry, *ops = NULL;
> > +
> > +	read_lock_irqsave(&dma_ops_list_lock, flags);
> > +
> > +	for (i = 0; i < DMA_OPS_TYPE_MAX; ++i)
> > +		list_for_each_entry(entry, &dma_ops_list[i], list) {
> > +			if (!entry->device_supported)
> > +				continue;
> > +			if (entry->device_supported(dev)) {
> > +				ops = entry;
> > +				goto out;
> > +			}
> > +		}
> > +out:
> > +	read_unlock_irqrestore(&dma_ops_list_lock, flags);
> 
> Hmm, every time we call dma_sg/map_single, we call
> read_lock_irqsave(&dma_ops_list_lock, flags). It's likely that we see
> notable performance drop?

Hmm, we should only call find_dma_ops_for_device() the first time a
dma api call is done (look into get_dma_ops). But I also thought about
how this lock can be avoided. In the real world it should not be
necessary because the dma_ops list is initialized before dma api calls
are done. But since there is now a register function which can be called
its safer this way. What do you think, are we still safe enough without
this lock?

Joerg


  reply	other threads:[~2008-09-28 18:44 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-22 18:21 [PATCH 0/9][RFC] stackable dma_ops for x86 Joerg Roedel
2008-09-22 18:21 ` [PATCH 1/9] x86/iommu: add necessary types for stackable dma_ops Joerg Roedel
2008-09-22 18:21 ` [PATCH 2/9] x86/iommu: add stackable dma_ops registration interface Joerg Roedel
2008-09-22 18:21 ` [PATCH 3/9] x86/iommu: change PCI-NOMMU to use dma_ops register interface Joerg Roedel
2008-09-22 18:21 ` [PATCH 4/9] x86/iommu: change SWIOTLB " Joerg Roedel
2008-09-22 18:21 ` [PATCH 5/9] x86/iommu: change GART " Joerg Roedel
2008-09-22 18:21 ` [PATCH 6/9] x86/iommu: change Calgary " Joerg Roedel
2008-09-23 14:37   ` Muli Ben-Yehuda
2008-09-30 11:10   ` Ingo Molnar
2008-09-30 11:58     ` Joerg Roedel
2008-09-30 13:30     ` Muli Ben-Yehuda
2008-09-30 15:38       ` Ingo Molnar
2008-09-30 18:33         ` Muli Ben-Yehuda
2008-09-22 18:21 ` [PATCH 7/9] x86/iommu: change AMD IOMMU " Joerg Roedel
2008-09-22 18:21 ` [PATCH 8/9] x86/iommu: change Intel " Joerg Roedel
2008-09-22 18:21 ` [PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops Joerg Roedel
2008-09-26  7:56   ` Amit Shah
2008-09-26  8:59     ` Joerg Roedel
2008-09-26 10:49       ` Amit Shah
2008-09-26 12:32         ` Joerg Roedel
2008-09-27  0:13           ` Muli Ben-Yehuda
2008-09-28 19:13             ` Joerg Roedel
2008-09-29  9:30               ` Muli Ben-Yehuda
2008-09-29  9:36                 ` Joerg Roedel
2008-09-29 13:16                   ` FUJITA Tomonori
2008-09-29 13:33                     ` Joerg Roedel
2008-09-30 19:44                       ` Muli Ben-Yehuda
2008-10-01  7:19                         ` Joerg Roedel
2008-10-03  8:38                           ` Muli Ben-Yehuda
2008-09-26 11:00     ` Joerg Roedel
2008-09-28 14:21   ` FUJITA Tomonori
2008-09-28 18:44     ` Joerg Roedel [this message]
2008-09-29  9:25       ` Muli Ben-Yehuda
2008-09-29  9:29         ` Joerg Roedel
2008-09-22 18:36 ` [PATCH 0/9][RFC] stackable dma_ops for x86 Arjan van de Ven
2008-09-22 18:39   ` Joerg Roedel
2008-09-23  2:41     ` Jeremy Fitzhardinge
2008-09-23  2:50       ` Arjan van de Ven
2008-09-28 14:21 ` FUJITA Tomonori
2008-09-28 18:49   ` Joerg Roedel
2008-09-29 13:16     ` FUJITA Tomonori
2008-09-29 13:26       ` Joerg Roedel
2008-09-29 13:42         ` FUJITA Tomonori
2008-09-29 13:51           ` Joerg Roedel

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=20080928184424.GA26563@8bytes.org \
    --to=joro@8bytes.org \
    --cc=amit.shah@qumranet.com \
    --cc=dwmw2@infradead.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=muli@il.ibm.com \
    /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.