From: Dan Williams <dan.j.williams@intel.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: pavel.tatashin@microsoft.com, "Michal Hocko" <mhocko@suse.com>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
"Dave Hansen" <dave.hansen@intel.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Linux MM" <linux-mm@kvack.org>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Ingo Molnar" <mingo@kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 4/4] nvdimm: Trigger the device probe on a cpu local to the device
Date: Tue, 11 Sep 2018 22:48:40 -0700 [thread overview]
Message-ID: <CAPcyv4gm30sT_us0j27jLmNTV_Fug4d8EW4xTmiTMFdwGSjN-A@mail.gmail.com> (raw)
In-Reply-To: <20180910234400.4068.15541.stgit@localhost.localdomain>
On Mon, Sep 10, 2018 at 4:44 PM, Alexander Duyck
<alexander.duyck@gmail.com> 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.
Yeah, it is a bit sad that we schedule an async thread only to move it
back somewhere else.
Could we trivially achieve the same with an
async_schedule_domain_on_cpu() variant? It seems we can and the
workqueue core will "Do the right thing".
I now notice that async uses the system_unbound_wq and work_on_cpu()
uses the system_wq. I don't think we want long running nvdimm work on
system_wq.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2018-09-12 5:48 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 [this message]
2018-09-12 13:44 ` Pasha Tatashin
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=CAPcyv4gm30sT_us0j27jLmNTV_Fug4d8EW4xTmiTMFdwGSjN-A@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=dave.hansen@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=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=pavel.tatashin@microsoft.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;
as well as URLs for NNTP newsgroup(s).