nvdimm.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Pasha Tatashin <Pavel.Tatashin@microsoft.com>
To: Alexander Duyck <alexander.duyck@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Cc: "mhocko@suse.com" <mhocko@suse.com>,
	"dave.jiang@intel.com" <dave.jiang@intel.com>,
	"mingo@kernel.org" <mingo@kernel.org>,
	"dave.hansen@intel.com" <dave.hansen@intel.com>,
	"jglisse@redhat.com" <jglisse@redhat.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"logang@deltatee.com" <logang@deltatee.com>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 4/4] nvdimm: Trigger the device probe on a cpu local to the device
Date: Wed, 12 Sep 2018 13:44:08 +0000	[thread overview]
Message-ID: <3b308b65-ab45-9922-abae-b4c25117e388@microsoft.com> (raw)
In-Reply-To: <20180910234400.4068.15541.stgit@localhost.localdomain>



On 9/10/18 7:44 PM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> 
> This patch is based off of the pci_call_probe function used to initialize
> PCI devices. The general idea here is to move the probe call to a location
> that is local to the memory being initialized. By doing this we can shave
> significant time off of the total time needed for initialization.
> 
> With this patch applied I see a significant reduction in overall init time
> as without it the init varied between 23 and 37 seconds to initialize a 3GB
> node. With this patch applied the variance is only between 23 and 26
> seconds to initialize each node.
> 
> I hope to refine this further in the future by combining this logic into
> the async_schedule_domain code that is already in use. By doing that it
> would likely make this functionality redundant.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>

Looks good to me. The previous fast runs were because there we were
getting lucky and executed in the right latency groups, right? Now, we
bound the execution time to be always fast.

Reviewed-by: Pavel Tatashin <pavel.tatashin@microsoft.com>

Thank you,
Pavel

      parent reply	other threads:[~2018-09-12 13:44 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 23:43 [PATCH 0/4] Address issues slowing persistent memory initialization Alexander Duyck
2018-09-10 23:43 ` [PATCH 1/4] mm: Provide kernel parameter to allow disabling page init poisoning Alexander Duyck
2018-09-11  0:35   ` Alexander Duyck
2018-09-11 16:50   ` Dan Williams
2018-09-11 20:01     ` Alexander Duyck
2018-09-11 20:24       ` Dan Williams
2018-09-12 13:24   ` Pasha Tatashin
2018-09-12 14:10   ` Michal Hocko
2018-09-12 14:49     ` Alexander Duyck
2018-09-12 15:23       ` Dave Hansen
2018-09-12 16:36         ` Alexander Duyck
2018-09-12 16:43           ` Dave Hansen
2018-09-10 23:43 ` [PATCH 2/4] mm: Create non-atomic version of SetPageReserved for init use Alexander Duyck
2018-09-12 13:28   ` Pasha Tatashin
2018-09-10 23:43 ` [PATCH 3/4] mm: Defer ZONE_DEVICE page initialization to the point where we init pgmap Alexander Duyck
2018-09-11  7:49   ` kbuild test robot
2018-09-11  7:54   ` kbuild test robot
2018-09-11 22:35   ` Dan Williams
2018-09-12  0:51     ` Alexander Duyck
2018-09-12  0:59       ` Dan Williams
2018-09-12 13:59   ` Pasha Tatashin
2018-09-12 15:48     ` Alexander Duyck
2018-09-12 15:54       ` Pasha Tatashin
2018-09-12 16:44         ` Alexander Duyck
2018-09-12 16:50       ` Dan Williams
2018-09-12 17:46         ` Pasha Tatashin
2018-09-12 19:11           ` Dan Williams
2018-09-10 23:44 ` [PATCH 4/4] nvdimm: Trigger the device probe on a cpu local to the device Alexander Duyck
2018-09-11  0:37   ` Alexander Duyck
2018-09-12  5:48   ` Dan Williams
2018-09-12 13:44   ` Pasha Tatashin [this message]

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=3b308b65-ab45-9922-abae-b4c25117e388@microsoft.com \
    --to=pavel.tatashin@microsoft.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.duyck@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=jglisse@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=logang@deltatee.com \
    --cc=mhocko@suse.com \
    --cc=mingo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).