All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 0/8] nfit, libnvdimm: async address range scrub
Date: Wed, 2 Mar 2016 01:45:03 +0000	[thread overview]
Message-ID: <1456883098.4525.9.camel@intel.com> (raw)
In-Reply-To: <20160224021655.22776.87952.stgit@dwillia2-desk3.amr.corp.intel.com>

On Tue, 2016-02-23 at 18:16 -0800, Dan Williams wrote:
> Given the capacities of next generation persistent memory devices a
> scrub operation to find all poison may take 10s of seconds.  We want
> this scrub work to be done asynchronously with the rest of system
> initialization, so we move it out of line from the NFIT probing, i.e.
> acpi_nfit_add().
> 
> However, we may want to synchronously wait for that scrubbing to
> complete before we probe any pmem devices.  Consider the case where
> consuming poison triggers a machine check and a reboot.  That event
> will
> trigger platform firmware to initiate a scrub.  The kernel should
> complete any firmware initiated scrubs as those likely indicate the
> presence of known poison.
> 
> When errors are not present, platform firmware did not initiate
> scrubbing, we still scrub, but asynchronously.  This trades off a risk
> of hitting new unknown poison ranges with making the data available
> faster after loading the driver.
> 
> This async scrub capability is also useful in the future when we
> integrate Tony Luck's mcsafe_copy() (or whatever it is
> eventually called).  After a machine check recovery event we can scrub
> the pmem namespace to see if there are any other latent errors and
> otherwise update the 'badblocks' list with the new entries.
> 
> This passes the libndctl unit test suite, with some minor updates to
> account for the fact that when "modprobe nfit_test" returns not all
> regions are registered.
> 
> ---
> 
> Dan Williams (8):
>       libnvdimm, nfit: centralize command status translation
>       libnvdimm: protect nvdimm_{bus|namespace}_add_poison() with
> nvdimm_bus_lock()
>       libnvdimm: async notification support
>       nfit, tools/testing/nvdimm: unify common init for acpi_nfit_desc
>       nfit, libnvdimm: async region scrub workqueue
>       nfit: scrub and register regions in a workqueue
>       nfit: disable userspace initiated ars during scrub
>       tools/testing/nvdimm: expand ars unit testing
> 
> 
>  drivers/acpi/nfit.c              |  761 +++++++++++++++++++++++++++
> -----------
>  drivers/acpi/nfit.h              |   24 +
>  drivers/nvdimm/bus.c             |   46 ++
>  drivers/nvdimm/core.c            |  110 ++++-
>  drivers/nvdimm/dimm_devs.c       |    6 
>  drivers/nvdimm/nd.h              |    2 
>  drivers/nvdimm/pmem.c            |   15 +
>  drivers/nvdimm/region.c          |   12 +
>  include/linux/libnvdimm.h        |    5 
>  include/linux/nd.h               |    7 
>  tools/testing/nvdimm/test/nfit.c |  133 +++++--
>  11 files changed, 809 insertions(+), 312 deletions(-)


Hi Dan,

Looks good to me, thanks for knocking this out!

For the series,
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>

WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Cc: "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/8] nfit, libnvdimm: async address range scrub
Date: Wed, 2 Mar 2016 01:45:03 +0000	[thread overview]
Message-ID: <1456883098.4525.9.camel@intel.com> (raw)
In-Reply-To: <20160224021655.22776.87952.stgit@dwillia2-desk3.amr.corp.intel.com>

On Tue, 2016-02-23 at 18:16 -0800, Dan Williams wrote:
> Given the capacities of next generation persistent memory devices a
> scrub operation to find all poison may take 10s of seconds.  We want
> this scrub work to be done asynchronously with the rest of system
> initialization, so we move it out of line from the NFIT probing, i.e.
> acpi_nfit_add().
> 
> However, we may want to synchronously wait for that scrubbing to
> complete before we probe any pmem devices.  Consider the case where
> consuming poison triggers a machine check and a reboot.  That event
> will
> trigger platform firmware to initiate a scrub.  The kernel should
> complete any firmware initiated scrubs as those likely indicate the
> presence of known poison.
> 
> When errors are not present, platform firmware did not initiate
> scrubbing, we still scrub, but asynchronously.  This trades off a risk
> of hitting new unknown poison ranges with making the data available
> faster after loading the driver.
> 
> This async scrub capability is also useful in the future when we
> integrate Tony Luck's mcsafe_copy() (or whatever it is
> eventually called).  After a machine check recovery event we can scrub
> the pmem namespace to see if there are any other latent errors and
> otherwise update the 'badblocks' list with the new entries.
> 
> This passes the libndctl unit test suite, with some minor updates to
> account for the fact that when "modprobe nfit_test" returns not all
> regions are registered.
> 
> ---
> 
> Dan Williams (8):
>       libnvdimm, nfit: centralize command status translation
>       libnvdimm: protect nvdimm_{bus|namespace}_add_poison() with
> nvdimm_bus_lock()
>       libnvdimm: async notification support
>       nfit, tools/testing/nvdimm: unify common init for acpi_nfit_desc
>       nfit, libnvdimm: async region scrub workqueue
>       nfit: scrub and register regions in a workqueue
>       nfit: disable userspace initiated ars during scrub
>       tools/testing/nvdimm: expand ars unit testing
> 
> 
>  drivers/acpi/nfit.c              |  761 +++++++++++++++++++++++++++
> -----------
>  drivers/acpi/nfit.h              |   24 +
>  drivers/nvdimm/bus.c             |   46 ++
>  drivers/nvdimm/core.c            |  110 ++++-
>  drivers/nvdimm/dimm_devs.c       |    6 
>  drivers/nvdimm/nd.h              |    2 
>  drivers/nvdimm/pmem.c            |   15 +
>  drivers/nvdimm/region.c          |   12 +
>  include/linux/libnvdimm.h        |    5 
>  include/linux/nd.h               |    7 
>  tools/testing/nvdimm/test/nfit.c |  133 +++++--
>  11 files changed, 809 insertions(+), 312 deletions(-)


Hi Dan,

Looks good to me, thanks for knocking this out!

For the series,
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: "Verma, Vishal L" <vishal.l.verma@intel.com>
To: "Williams, Dan J" <dan.j.williams@intel.com>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 0/8] nfit, libnvdimm: async address range scrub
Date: Wed, 2 Mar 2016 01:45:03 +0000	[thread overview]
Message-ID: <1456883098.4525.9.camel@intel.com> (raw)
In-Reply-To: <20160224021655.22776.87952.stgit@dwillia2-desk3.amr.corp.intel.com>

On Tue, 2016-02-23 at 18:16 -0800, Dan Williams wrote:
> Given the capacities of next generation persistent memory devices a
> scrub operation to find all poison may take 10s of seconds.  We want
> this scrub work to be done asynchronously with the rest of system
> initialization, so we move it out of line from the NFIT probing, i.e.
> acpi_nfit_add().
> 
> However, we may want to synchronously wait for that scrubbing to
> complete before we probe any pmem devices.  Consider the case where
> consuming poison triggers a machine check and a reboot.  That event
> will
> trigger platform firmware to initiate a scrub.  The kernel should
> complete any firmware initiated scrubs as those likely indicate the
> presence of known poison.
> 
> When errors are not present, platform firmware did not initiate
> scrubbing, we still scrub, but asynchronously.  This trades off a risk
> of hitting new unknown poison ranges with making the data available
> faster after loading the driver.
> 
> This async scrub capability is also useful in the future when we
> integrate Tony Luck's mcsafe_copy() (or whatever it is
> eventually called).  After a machine check recovery event we can scrub
> the pmem namespace to see if there are any other latent errors and
> otherwise update the 'badblocks' list with the new entries.
> 
> This passes the libndctl unit test suite, with some minor updates to
> account for the fact that when "modprobe nfit_test" returns not all
> regions are registered.
> 
> ---
> 
> Dan Williams (8):
>       libnvdimm, nfit: centralize command status translation
>       libnvdimm: protect nvdimm_{bus|namespace}_add_poison() with
> nvdimm_bus_lock()
>       libnvdimm: async notification support
>       nfit, tools/testing/nvdimm: unify common init for acpi_nfit_desc
>       nfit, libnvdimm: async region scrub workqueue
>       nfit: scrub and register regions in a workqueue
>       nfit: disable userspace initiated ars during scrub
>       tools/testing/nvdimm: expand ars unit testing
> 
> 
>  drivers/acpi/nfit.c              |  761 +++++++++++++++++++++++++++
> -----------
>  drivers/acpi/nfit.h              |   24 +
>  drivers/nvdimm/bus.c             |   46 ++
>  drivers/nvdimm/core.c            |  110 ++++-
>  drivers/nvdimm/dimm_devs.c       |    6 
>  drivers/nvdimm/nd.h              |    2 
>  drivers/nvdimm/pmem.c            |   15 +
>  drivers/nvdimm/region.c          |   12 +
>  include/linux/libnvdimm.h        |    5 
>  include/linux/nd.h               |    7 
>  tools/testing/nvdimm/test/nfit.c |  133 +++++--
>  11 files changed, 809 insertions(+), 312 deletions(-)


Hi Dan,

Looks good to me, thanks for knocking this out!

For the series,
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>

  parent reply	other threads:[~2016-03-02  1:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  2:16 [PATCH 0/8] nfit, libnvdimm: async address range scrub Dan Williams
2016-02-24  2:16 ` Dan Williams
2016-02-24  2:17 ` [PATCH 1/8] libnvdimm, nfit: centralize command status translation Dan Williams
2016-02-24  2:17   ` Dan Williams
2016-02-24  2:17 ` [PATCH 2/8] libnvdimm: protect nvdimm_{bus|namespace}_add_poison() with nvdimm_bus_lock() Dan Williams
2016-02-24  2:17   ` Dan Williams
2016-02-24  2:17 ` [PATCH 3/8] libnvdimm: async notification support Dan Williams
2016-02-24  2:17   ` Dan Williams
2016-02-24  2:17 ` [PATCH 4/8] nfit, tools/testing/nvdimm: unify common init for acpi_nfit_desc Dan Williams
2016-02-24  2:17   ` Dan Williams
2016-02-24  2:17 ` [PATCH 5/8] nfit, libnvdimm: async region scrub workqueue Dan Williams
2016-02-24  2:17   ` Dan Williams
2016-02-24  2:17 ` [PATCH 6/8] nfit: scrub and register regions in a workqueue Dan Williams
2016-02-24  2:17   ` Dan Williams
2016-02-24  2:17 ` [PATCH 7/8] nfit: disable userspace initiated ars during scrub Dan Williams
2016-02-24  2:17   ` Dan Williams
2016-02-24  2:17 ` [PATCH 8/8] tools/testing/nvdimm: expand ars unit testing Dan Williams
2016-02-24  2:17   ` Dan Williams
2016-03-02  1:45 ` Verma, Vishal L [this message]
2016-03-02  1:45   ` [PATCH 0/8] nfit, libnvdimm: async address range scrub Verma, Vishal L
2016-03-02  1:45   ` Verma, Vishal L

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=1456883098.4525.9.camel@intel.com \
    --to=vishal.l.verma@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.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 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.