All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Joerg Roedel <joro@8bytes.org>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
	netdev@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH 03/10] x86: add initialization code for DMA-API debugging
Date: Sun, 23 Nov 2008 12:35:43 +0100	[thread overview]
Message-ID: <20081123113543.GD29663@elte.hu> (raw)
In-Reply-To: <20081123112818.GC29663@elte.hu>


* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Joerg Roedel <joro@8bytes.org> wrote:
> 
> > On Fri, Nov 21, 2008 at 06:43:48PM +0100, Ingo Molnar wrote:
> > > 
> > > * Joerg Roedel <joerg.roedel@amd.com> wrote:
> > > 
> > > > +static struct list_head dma_entry_hash[HASH_SIZE];
> > > > +
> > > > +/* A slab cache to allocate dma_map_entries fast */
> > > > +static struct kmem_cache *dma_entry_cache;
> > > > +
> > > > +/* lock to protect the data structures */
> > > > +static DEFINE_SPINLOCK(dma_lock);
> > > 
> > > some more generic comments about the data structure: it's main purpose 
> > > is to provide a mapping based on (dev,addr). There's little if any 
> > > cross-entry interaction - same-address+same-dev DMA is checked.
> > > 
> > > 1)
> > > 
> > > the hash:
> > > 
> > > + 	return (entry->dev_addr >> HASH_FN_SHIFT) & HASH_FN_MASK;
> > > 
> > > should mix in entry->dev as well - that way we get not just per 
> > > address but per device hash space separation as well.
> > > 
> > > 2)
> > > 
> > > HASH_FN_SHIFT is 1MB chunks right now - that's probably fine in 
> > > practice albeit perhaps a bit too small. There's seldom any coherency 
> > > between the physical addresses of DMA - we rarely have any real 
> > > (performance-relevant) physical co-location of DMA addresses beyond 4K 
> > > granularity. So using 1MB chunking here will discard a good deal of 
> > > random low bits we should be hashing on.
> > > 
> > > 3)
> > > 
> > > And the most scalable locking would be per hash bucket locking - no 
> > > global lock is needed. The bucket hash heads should probably be 
> > > cacheline sized - so we'd get one lock per bucket.
> > 
> > Hmm, I just had the idea of saving this data in struct device. How 
> > about that? The locking should scale too and we can extend it 
> > easier. For example it simplifys a per-device disable function for 
> > the checking. Or another future feature might be leak tracing.
> 
> that will help with spreading the hash across devices, but brings in 
> lifetime issues: you must be absolutely sure all DMA has drained at 
> the point a device is deinitialized.

Note that obviously proper DMA quiescence is a must-have during device 
dinit anyway, but still, it's an extra complication to init/deinit the 
hashes, etc.

	Ingo

  reply	other threads:[~2008-11-23 11:36 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-21 16:26 [PATCH 0/10] DMA-API debugging facility Joerg Roedel
2008-11-21 16:26 ` [PATCH 01/10] x86: add Kconfig entry for DMA-API debugging Joerg Roedel
2008-11-21 16:40   ` Ingo Molnar
2008-11-21 16:48     ` Joerg Roedel
2008-11-21 23:18   ` David Miller
2008-11-21 16:26 ` [PATCH 02/10] x86: add data structures " Joerg Roedel
2008-11-21 16:42   ` Ingo Molnar
2008-11-21 16:49     ` Joerg Roedel
2008-11-21 16:26 ` [PATCH 03/10] x86: add initialization code " Joerg Roedel
2008-11-21 16:56   ` Ingo Molnar
2008-11-21 17:10     ` Joerg Roedel
2008-11-21 17:19       ` Ingo Molnar
2008-11-21 17:27         ` Ingo Molnar
2008-11-21 17:43   ` Ingo Molnar
2008-11-22  9:48     ` Joerg Roedel
2008-11-23 11:28       ` Ingo Molnar
2008-11-23 11:35         ` Ingo Molnar [this message]
2008-11-23 13:04         ` Ingo Molnar
2008-11-22  3:27   ` FUJITA Tomonori
2008-11-22  9:40     ` Joerg Roedel
2008-11-22 10:16       ` FUJITA Tomonori
2008-11-22 12:28         ` FUJITA Tomonori
2008-11-23 19:36   ` Andi Kleen
2008-11-21 16:26 ` [PATCH 04/10] x86: add helper functions for consistency checks Joerg Roedel
2008-11-21 17:07   ` Ingo Molnar
2008-11-21 16:26 ` [PATCH 05/10] x86: add check code for map/unmap_single code Joerg Roedel
2008-11-22  3:27   ` FUJITA Tomonori
2008-11-22  9:39     ` Joerg Roedel
2008-11-21 16:26 ` [PATCH 06/10] x86: add check code for map/unmap_sg code Joerg Roedel
2008-11-21 16:58   ` Ingo Molnar
2008-11-21 17:10   ` Ingo Molnar
2008-11-21 16:26 ` [PATCH 07/10] x86: add checks for alloc/free_coherent code Joerg Roedel
2008-11-21 16:57   ` Ingo Molnar
2008-11-22  3:27   ` FUJITA Tomonori
2008-11-22  9:38     ` Joerg Roedel
2008-11-21 16:26 ` [PATCH 08/10] x86: add checks for sync_single* code Joerg Roedel
2008-11-21 16:26 ` [PATCH 09/10] x86: add checks for sync_single_range* code Joerg Roedel
2008-11-21 16:26 ` [PATCH 10/10] x86: add checks for sync_sg* code Joerg Roedel
2008-11-21 16:59   ` Ingo Molnar
2008-11-21 16:37 ` [PATCH 0/10] DMA-API debugging facility Ingo Molnar
2008-11-21 16:40   ` Joerg Roedel
2008-11-21 16:52 ` Joerg Roedel
2008-11-21 16:54 ` David Woodhouse
2008-11-21 16:57   ` Joerg Roedel
2008-11-21 17:03     ` Ingo Molnar
2008-11-21 17:06     ` David Woodhouse
2008-11-21 17:18       ` Ingo Molnar
2008-11-21 17:20         ` Joerg Roedel
2008-11-21 17:24           ` David Woodhouse
2008-11-21 17:27             ` Joerg Roedel
2008-11-21 17:45               ` Ingo Molnar
2008-11-22  3:27                 ` FUJITA Tomonori
2008-11-22  9:33                   ` Joerg Roedel
2008-11-22 10:16                     ` FUJITA Tomonori
2009-02-05 22:44               ` David Woodhouse
2009-02-25  8:11                 ` David Woodhouse
2009-02-25  8:11                   ` David Woodhouse
2009-07-01 13:19                 ` [PATCH] Support DMA-API debugging facility on PowerPC David Woodhouse
2009-07-01 14:00                   ` Christoph Hellwig
2009-07-01 18:34                   ` Joerg Roedel
2009-07-02 14:09                   ` Kumar Gala
2009-07-02 14:09                     ` Kumar Gala
2008-11-21 17:22         ` [PATCH 0/10] DMA-API debugging facility David Woodhouse
2008-11-22  3:27 ` FUJITA Tomonori
2008-11-22  9:29   ` 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=20081123113543.GD29663@elte.hu \
    --to=mingo@elte.hu \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joerg.roedel@amd.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --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.