All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roedel, Joerg" <Joerg.Roedel@amd.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Divy LeRay <divy@chelsio.com>,
	Stanislaw Gruszka <sgruszka@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] dma-debug: hash_bucket_find needs to allow for offsets within an entry
Date: Wed, 20 Jul 2011 16:59:01 +0200	[thread overview]
Message-ID: <20110720145901.GE21948@amd.com> (raw)
In-Reply-To: <20110720143222.GB12349@hmsreliant.think-freely.org>

On Wed, Jul 20, 2011 at 10:32:22AM -0400, Neil Horman wrote:
> On Wed, Jul 20, 2011 at 03:29:25PM +0200, Roedel, Joerg wrote:
> > You are right. We need to scan
> > 
> > 	0 <= idx <= hash_fn(rstart)
> > 
> > Probably we can fix that with a better hash-function. Any ideas? Using
> > the device is not an option because then all entries would end up in
> > only a few buckets. This will impact scanning performance too much.
> > 
> Unfortunately I don't have any ideas for a better hash function here, but I had
> been thinking about fixing this in add_dma_entry.  We could detect there that a
> debug entry to be added crossed one or more hash bucket boundaries, and, if it
> did, split it along those boundaries into multiple entries, hashing each of them
> in separately.  The check_unmap and check_sync routines would of course then
> potentially have to do multiple lookups as well to ensure that they found all of
> the correct entries to validate/remove.  It would work in all cases, but it
> might be overkill.  What do you think?

Interesting. I discussed that with a colleague an hour ago and he came
up with the same idea :-)
I like it because we still need to scan only one hash-bucket, so this
seems like the best solution.

> > For now, the partial syncs seem to happen rarely enough so that we can
> > make it a slow-path. It is probably the best to do the exact scan first
> > and do the full scan only if exact-scan failed (until we come up with a
> > better solution).
> > 
> Agreed, if you don't like my above idea, I'll get to work on this this
> afternoon.

I think this idea is a better solution.

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632


  reply	other threads:[~2011-07-20 14:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-19 17:41 [PATCH] dma-debug: hash_bucket_find needs to allow for offsets within an entry Neil Horman
2011-07-20 10:38 ` Roedel, Joerg
2011-07-20 11:11   ` Neil Horman
2011-07-20 13:29     ` Roedel, Joerg
2011-07-20 14:32       ` Neil Horman
2011-07-20 14:59         ` Roedel, Joerg [this message]
2011-07-20 15:12           ` Neil Horman
2011-08-08 19:13 ` [PATCH] dma-debug: hash_bucket_find needs to allow for offsets within an entry (v2) Neil Horman
2011-08-10 13:31   ` Roedel, Joerg
2011-08-10 14:47     ` Neil Horman
2011-08-22 10:46     ` Neil Horman
2011-08-22 12:44       ` Roedel, Joerg
2011-08-22 13:20         ` Neil Horman
2011-08-22 16:46   ` Roedel, Joerg
2011-08-22 17:23     ` Neil Horman

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=20110720145901.GE21948@amd.com \
    --to=joerg.roedel@amd.com \
    --cc=arnd@arndb.de \
    --cc=divy@chelsio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=sgruszka@redhat.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.