Linux-NVME Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH 1/1] Replace the dma_alloc_coherent() with dma_zalloc_coherent()
Date: Wed, 16 Jul 2014 08:52:55 -0600 (MDT)	[thread overview]
Message-ID: <alpine.LRH.2.03.1407160844140.4703@AMR> (raw)
In-Reply-To: <20140716141632.GI5855@linux.intel.com>

On Wed, 16 Jul 2014, Matthew Wilcox wrote:
> On Wed, Jul 16, 2014@11:27:38AM +0530, mundu agarwal wrote:
>> Willy,
>>
>> There is patch merged for dma_zalloc_coherent for cqee to avoid the
>> memset, where as memset still happing for same in nvme_init_queue. I
>> guess this is not needed, and rest are to maintain the consistancy. I
>> feel instead of mix use of the apis, should be use as clean/single
>> one. There are couple of places during initialization variables are
>> reseting to 0 after allocating the memory using zalloc which we can
>> avoid. In case this patch ok then my next task will be doing the
>> cleanup without any impacting the current functionality.
>
> Better not to guess.  Joe's quite careful to only do the ones that are
> obviously correct.  I believe your patches to be incorrect, since some of
> the places don't need to be zeroed (eg SQEs are zeroed before each use).
>
> In the specific case of nvme_init_queue() zeroing the memory, I think
> it's necessary on that path because that path is called on resume from
> D3 and we need to reinitialise the CQ state to all zeroes.  Keith should
> be able to confirm that.

Yes, we have to clear the cmdid data and completion queues in init for
the resume and reset cases otherwise we would leak command id's that
were active at the time we shut down the device, or potentially read a
stale cq "phase" and misinterpret that as a new completion.

  reply	other threads:[~2014-07-16 14:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15 18:11 [PATCH 1/1] Replace the dma_alloc_coherent() with dma_zalloc_coherent() Mundu
2014-07-15 18:28 ` Matthew Wilcox
2014-07-16  5:57   ` mundu agarwal
2014-07-16 14:16     ` Matthew Wilcox
2014-07-16 14:52       ` Keith Busch [this message]
2014-07-16 17:08         ` mundu agarwal

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=alpine.LRH.2.03.1407160844140.4703@AMR \
    --to=keith.busch@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox