libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
/*
|
|
|
|
* Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of version 2 of the GNU General Public License as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*/
|
2015-05-01 17:11:27 +00:00
|
|
|
#include <linux/scatterlist.h>
|
2015-06-25 08:21:02 +00:00
|
|
|
#include <linux/highmem.h>
|
2015-05-01 17:11:27 +00:00
|
|
|
#include <linux/sched.h>
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
#include <linux/slab.h>
|
2016-05-27 16:23:01 +00:00
|
|
|
#include <linux/hash.h>
|
2016-07-08 02:44:50 +00:00
|
|
|
#include <linux/pmem.h>
|
2015-05-01 17:11:27 +00:00
|
|
|
#include <linux/sort.h>
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
#include <linux/io.h>
|
2015-06-17 21:14:46 +00:00
|
|
|
#include <linux/nd.h>
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
#include "nd-core.h"
|
|
|
|
#include "nd.h"
|
|
|
|
|
2016-07-08 02:44:50 +00:00
|
|
|
/*
|
|
|
|
* For readq() and writeq() on 32-bit builds, the hi-lo, lo-hi order is
|
|
|
|
* irrelevant.
|
|
|
|
*/
|
|
|
|
#include <linux/io-64-nonatomic-hi-lo.h>
|
|
|
|
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
static DEFINE_IDA(region_ida);
|
2016-05-27 16:23:01 +00:00
|
|
|
static DEFINE_PER_CPU(int, flush_idx);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
|
2016-06-08 00:00:04 +00:00
|
|
|
static int nvdimm_map_flush(struct device *dev, struct nvdimm *nvdimm, int dimm,
|
|
|
|
struct nd_region_data *ndrd)
|
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
dev_dbg(dev, "%s: map %d flush address%s\n", nvdimm_name(nvdimm),
|
|
|
|
nvdimm->num_flush, nvdimm->num_flush == 1 ? "" : "es");
|
2016-09-24 00:53:52 +00:00
|
|
|
for (i = 0; i < (1 << ndrd->hints_shift); i++) {
|
2016-06-08 00:00:04 +00:00
|
|
|
struct resource *res = &nvdimm->flush_wpq[i];
|
|
|
|
unsigned long pfn = PHYS_PFN(res->start);
|
|
|
|
void __iomem *flush_page;
|
|
|
|
|
|
|
|
/* check if flush hints share a page */
|
|
|
|
for (j = 0; j < i; j++) {
|
|
|
|
struct resource *res_j = &nvdimm->flush_wpq[j];
|
|
|
|
unsigned long pfn_j = PHYS_PFN(res_j->start);
|
|
|
|
|
|
|
|
if (pfn == pfn_j)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (j < i)
|
|
|
|
flush_page = (void __iomem *) ((unsigned long)
|
2016-09-24 00:53:52 +00:00
|
|
|
ndrd_get_flush_wpq(ndrd, dimm, j)
|
|
|
|
& PAGE_MASK);
|
2016-06-08 00:00:04 +00:00
|
|
|
else
|
|
|
|
flush_page = devm_nvdimm_ioremap(dev,
|
2016-09-19 10:19:00 +00:00
|
|
|
PFN_PHYS(pfn), PAGE_SIZE);
|
2016-06-08 00:00:04 +00:00
|
|
|
if (!flush_page)
|
|
|
|
return -ENXIO;
|
2016-09-24 00:53:52 +00:00
|
|
|
ndrd_set_flush_wpq(ndrd, dimm, i, flush_page
|
|
|
|
+ (res->start & ~PAGE_MASK));
|
2016-06-08 00:00:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int nd_region_activate(struct nd_region *nd_region)
|
|
|
|
{
|
2016-09-26 18:06:50 +00:00
|
|
|
int i, j, num_flush = 0;
|
2016-06-08 00:00:04 +00:00
|
|
|
struct nd_region_data *ndrd;
|
|
|
|
struct device *dev = &nd_region->dev;
|
|
|
|
size_t flush_data_size = sizeof(void *);
|
|
|
|
|
|
|
|
nvdimm_bus_lock(&nd_region->dev);
|
|
|
|
for (i = 0; i < nd_region->ndr_mappings; i++) {
|
|
|
|
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
|
|
|
|
struct nvdimm *nvdimm = nd_mapping->nvdimm;
|
|
|
|
|
|
|
|
/* at least one null hint slot per-dimm for the "no-hint" case */
|
|
|
|
flush_data_size += sizeof(void *);
|
2016-05-27 16:23:01 +00:00
|
|
|
num_flush = min_not_zero(num_flush, nvdimm->num_flush);
|
2016-06-08 00:00:04 +00:00
|
|
|
if (!nvdimm->num_flush)
|
|
|
|
continue;
|
|
|
|
flush_data_size += nvdimm->num_flush * sizeof(void *);
|
|
|
|
}
|
|
|
|
nvdimm_bus_unlock(&nd_region->dev);
|
|
|
|
|
|
|
|
ndrd = devm_kzalloc(dev, sizeof(*ndrd) + flush_data_size, GFP_KERNEL);
|
|
|
|
if (!ndrd)
|
|
|
|
return -ENOMEM;
|
|
|
|
dev_set_drvdata(dev, ndrd);
|
|
|
|
|
2016-09-24 00:53:52 +00:00
|
|
|
if (!num_flush)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
ndrd->hints_shift = ilog2(num_flush);
|
2016-06-08 00:00:04 +00:00
|
|
|
for (i = 0; i < nd_region->ndr_mappings; i++) {
|
|
|
|
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
|
|
|
|
struct nvdimm *nvdimm = nd_mapping->nvdimm;
|
|
|
|
int rc = nvdimm_map_flush(&nd_region->dev, nvdimm, i, ndrd);
|
|
|
|
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2016-09-26 18:06:50 +00:00
|
|
|
/*
|
|
|
|
* Clear out entries that are duplicates. This should prevent the
|
|
|
|
* extra flushings.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < nd_region->ndr_mappings - 1; i++) {
|
|
|
|
/* ignore if NULL already */
|
|
|
|
if (!ndrd_get_flush_wpq(ndrd, i, 0))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (j = i + 1; j < nd_region->ndr_mappings; j++)
|
|
|
|
if (ndrd_get_flush_wpq(ndrd, i, 0) ==
|
|
|
|
ndrd_get_flush_wpq(ndrd, j, 0))
|
|
|
|
ndrd_set_flush_wpq(ndrd, j, 0, NULL);
|
|
|
|
}
|
|
|
|
|
2016-06-08 00:00:04 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
static void nd_region_release(struct device *dev)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
u16 i;
|
|
|
|
|
|
|
|
for (i = 0; i < nd_region->ndr_mappings; i++) {
|
|
|
|
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
|
|
|
|
struct nvdimm *nvdimm = nd_mapping->nvdimm;
|
|
|
|
|
|
|
|
put_device(&nvdimm->dev);
|
|
|
|
}
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
free_percpu(nd_region->lane);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
ida_simple_remove(®ion_ida, nd_region->id);
|
2015-06-25 08:21:02 +00:00
|
|
|
if (is_nd_blk(dev))
|
|
|
|
kfree(to_nd_blk_region(dev));
|
|
|
|
else
|
|
|
|
kfree(nd_region);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct device_type nd_blk_device_type = {
|
|
|
|
.name = "nd_blk",
|
|
|
|
.release = nd_region_release,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct device_type nd_pmem_device_type = {
|
|
|
|
.name = "nd_pmem",
|
|
|
|
.release = nd_region_release,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct device_type nd_volatile_device_type = {
|
|
|
|
.name = "nd_volatile",
|
|
|
|
.release = nd_region_release,
|
|
|
|
};
|
|
|
|
|
2015-05-31 19:02:11 +00:00
|
|
|
bool is_nd_pmem(struct device *dev)
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
{
|
|
|
|
return dev ? dev->type == &nd_pmem_device_type : false;
|
|
|
|
}
|
|
|
|
|
2015-05-31 19:02:11 +00:00
|
|
|
bool is_nd_blk(struct device *dev)
|
|
|
|
{
|
|
|
|
return dev ? dev->type == &nd_blk_device_type : false;
|
|
|
|
}
|
|
|
|
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
struct nd_region *to_nd_region(struct device *dev)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = container_of(dev, struct nd_region, dev);
|
|
|
|
|
|
|
|
WARN_ON(dev->type->release != nd_region_release);
|
|
|
|
return nd_region;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(to_nd_region);
|
|
|
|
|
2015-06-25 08:21:02 +00:00
|
|
|
struct nd_blk_region *to_nd_blk_region(struct device *dev)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
|
|
|
|
WARN_ON(!is_nd_blk(dev));
|
|
|
|
return container_of(nd_region, struct nd_blk_region, nd_region);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(to_nd_blk_region);
|
|
|
|
|
|
|
|
void *nd_region_provider_data(struct nd_region *nd_region)
|
|
|
|
{
|
|
|
|
return nd_region->provider_data;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(nd_region_provider_data);
|
|
|
|
|
|
|
|
void *nd_blk_region_provider_data(struct nd_blk_region *ndbr)
|
|
|
|
{
|
|
|
|
return ndbr->blk_provider_data;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(nd_blk_region_provider_data);
|
|
|
|
|
|
|
|
void nd_blk_region_set_provider_data(struct nd_blk_region *ndbr, void *data)
|
|
|
|
{
|
|
|
|
ndbr->blk_provider_data = data;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(nd_blk_region_set_provider_data);
|
|
|
|
|
2015-05-31 19:02:11 +00:00
|
|
|
/**
|
|
|
|
* nd_region_to_nstype() - region to an integer namespace type
|
|
|
|
* @nd_region: region-device to interrogate
|
|
|
|
*
|
|
|
|
* This is the 'nstype' attribute of a region as well, an input to the
|
|
|
|
* MODALIAS for namespace devices, and bit number for a nvdimm_bus to match
|
|
|
|
* namespace devices with namespace drivers.
|
|
|
|
*/
|
|
|
|
int nd_region_to_nstype(struct nd_region *nd_region)
|
|
|
|
{
|
|
|
|
if (is_nd_pmem(&nd_region->dev)) {
|
|
|
|
u16 i, alias;
|
|
|
|
|
|
|
|
for (i = 0, alias = 0; i < nd_region->ndr_mappings; i++) {
|
|
|
|
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
|
|
|
|
struct nvdimm *nvdimm = nd_mapping->nvdimm;
|
|
|
|
|
|
|
|
if (nvdimm->flags & NDD_ALIASING)
|
|
|
|
alias++;
|
|
|
|
}
|
|
|
|
if (alias)
|
|
|
|
return ND_DEVICE_NAMESPACE_PMEM;
|
|
|
|
else
|
|
|
|
return ND_DEVICE_NAMESPACE_IO;
|
|
|
|
} else if (is_nd_blk(&nd_region->dev)) {
|
|
|
|
return ND_DEVICE_NAMESPACE_BLK;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2015-06-17 21:14:46 +00:00
|
|
|
EXPORT_SYMBOL(nd_region_to_nstype);
|
|
|
|
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
static ssize_t size_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
unsigned long long size = 0;
|
|
|
|
|
|
|
|
if (is_nd_pmem(dev)) {
|
|
|
|
size = nd_region->ndr_size;
|
|
|
|
} else if (nd_region->ndr_mappings == 1) {
|
|
|
|
struct nd_mapping *nd_mapping = &nd_region->mapping[0];
|
|
|
|
|
|
|
|
size = nd_mapping->size;
|
|
|
|
}
|
|
|
|
|
|
|
|
return sprintf(buf, "%llu\n", size);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(size);
|
|
|
|
|
|
|
|
static ssize_t mappings_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
|
|
|
|
return sprintf(buf, "%d\n", nd_region->ndr_mappings);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(mappings);
|
|
|
|
|
2015-05-31 19:02:11 +00:00
|
|
|
static ssize_t nstype_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
|
|
|
|
return sprintf(buf, "%d\n", nd_region_to_nstype(nd_region));
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(nstype);
|
|
|
|
|
2015-05-01 17:11:27 +00:00
|
|
|
static ssize_t set_cookie_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
struct nd_interleave_set *nd_set = nd_region->nd_set;
|
|
|
|
|
|
|
|
if (is_nd_pmem(dev) && nd_set)
|
|
|
|
/* pass, should be precluded by region_visible */;
|
|
|
|
else
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
return sprintf(buf, "%#llx\n", nd_set->cookie);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(set_cookie);
|
|
|
|
|
2015-06-17 21:14:46 +00:00
|
|
|
resource_size_t nd_region_available_dpa(struct nd_region *nd_region)
|
|
|
|
{
|
|
|
|
resource_size_t blk_max_overlap = 0, available, overlap;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
WARN_ON(!is_nvdimm_bus_locked(&nd_region->dev));
|
|
|
|
|
|
|
|
retry:
|
|
|
|
available = 0;
|
|
|
|
overlap = blk_max_overlap;
|
|
|
|
for (i = 0; i < nd_region->ndr_mappings; i++) {
|
|
|
|
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
|
|
|
|
struct nvdimm_drvdata *ndd = to_ndd(nd_mapping);
|
|
|
|
|
|
|
|
/* if a dimm is disabled the available capacity is zero */
|
|
|
|
if (!ndd)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (is_nd_pmem(&nd_region->dev)) {
|
|
|
|
available += nd_pmem_available_dpa(nd_region,
|
|
|
|
nd_mapping, &overlap);
|
|
|
|
if (overlap > blk_max_overlap) {
|
|
|
|
blk_max_overlap = overlap;
|
|
|
|
goto retry;
|
|
|
|
}
|
2016-10-01 00:28:58 +00:00
|
|
|
} else if (is_nd_blk(&nd_region->dev))
|
|
|
|
available += nd_blk_available_dpa(nd_region);
|
2015-06-17 21:14:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return available;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t available_size_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
unsigned long long available = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Flush in-flight updates and grab a snapshot of the available
|
|
|
|
* size. Of course, this value is potentially invalidated the
|
|
|
|
* memory nvdimm_bus_lock() is dropped, but that's userspace's
|
|
|
|
* problem to not race itself.
|
|
|
|
*/
|
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
wait_nvdimm_bus_probe_idle(dev);
|
|
|
|
available = nd_region_available_dpa(nd_region);
|
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
|
|
|
|
return sprintf(buf, "%llu\n", available);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(available_size);
|
|
|
|
|
2015-05-31 19:02:11 +00:00
|
|
|
static ssize_t init_namespaces_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
2016-06-08 00:00:04 +00:00
|
|
|
struct nd_region_data *ndrd = dev_get_drvdata(dev);
|
2015-05-31 19:02:11 +00:00
|
|
|
ssize_t rc;
|
|
|
|
|
|
|
|
nvdimm_bus_lock(dev);
|
2016-06-08 00:00:04 +00:00
|
|
|
if (ndrd)
|
|
|
|
rc = sprintf(buf, "%d/%d\n", ndrd->ns_active, ndrd->ns_count);
|
2015-05-31 19:02:11 +00:00
|
|
|
else
|
|
|
|
rc = -ENXIO;
|
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(init_namespaces);
|
|
|
|
|
2015-06-17 21:14:46 +00:00
|
|
|
static ssize_t namespace_seed_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
ssize_t rc;
|
|
|
|
|
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
if (nd_region->ns_seed)
|
|
|
|
rc = sprintf(buf, "%s\n", dev_name(nd_region->ns_seed));
|
|
|
|
else
|
|
|
|
rc = sprintf(buf, "\n");
|
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(namespace_seed);
|
|
|
|
|
2015-06-25 08:20:04 +00:00
|
|
|
static ssize_t btt_seed_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
ssize_t rc;
|
|
|
|
|
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
if (nd_region->btt_seed)
|
|
|
|
rc = sprintf(buf, "%s\n", dev_name(nd_region->btt_seed));
|
|
|
|
else
|
|
|
|
rc = sprintf(buf, "\n");
|
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(btt_seed);
|
|
|
|
|
2015-07-30 21:57:47 +00:00
|
|
|
static ssize_t pfn_seed_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
ssize_t rc;
|
|
|
|
|
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
if (nd_region->pfn_seed)
|
|
|
|
rc = sprintf(buf, "%s\n", dev_name(nd_region->pfn_seed));
|
|
|
|
else
|
|
|
|
rc = sprintf(buf, "\n");
|
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(pfn_seed);
|
|
|
|
|
2016-03-11 18:15:36 +00:00
|
|
|
static ssize_t dax_seed_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
ssize_t rc;
|
|
|
|
|
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
if (nd_region->dax_seed)
|
|
|
|
rc = sprintf(buf, "%s\n", dev_name(nd_region->dax_seed));
|
|
|
|
else
|
|
|
|
rc = sprintf(buf, "\n");
|
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(dax_seed);
|
|
|
|
|
2015-06-24 00:08:34 +00:00
|
|
|
static ssize_t read_only_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
|
|
|
|
return sprintf(buf, "%d\n", nd_region->ro);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t read_only_store(struct device *dev,
|
|
|
|
struct device_attribute *attr, const char *buf, size_t len)
|
|
|
|
{
|
|
|
|
bool ro;
|
|
|
|
int rc = strtobool(buf, &ro);
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
nd_region->ro = ro;
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RW(read_only);
|
|
|
|
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
static struct attribute *nd_region_attributes[] = {
|
|
|
|
&dev_attr_size.attr,
|
2015-05-31 19:02:11 +00:00
|
|
|
&dev_attr_nstype.attr,
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
&dev_attr_mappings.attr,
|
2015-06-25 08:20:04 +00:00
|
|
|
&dev_attr_btt_seed.attr,
|
2015-07-30 21:57:47 +00:00
|
|
|
&dev_attr_pfn_seed.attr,
|
2016-03-11 18:15:36 +00:00
|
|
|
&dev_attr_dax_seed.attr,
|
2015-06-24 00:08:34 +00:00
|
|
|
&dev_attr_read_only.attr,
|
2015-05-01 17:11:27 +00:00
|
|
|
&dev_attr_set_cookie.attr,
|
2015-06-17 21:14:46 +00:00
|
|
|
&dev_attr_available_size.attr,
|
|
|
|
&dev_attr_namespace_seed.attr,
|
2015-05-31 19:02:11 +00:00
|
|
|
&dev_attr_init_namespaces.attr,
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2015-05-01 17:11:27 +00:00
|
|
|
static umode_t region_visible(struct kobject *kobj, struct attribute *a, int n)
|
|
|
|
{
|
|
|
|
struct device *dev = container_of(kobj, typeof(*dev), kobj);
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
struct nd_interleave_set *nd_set = nd_region->nd_set;
|
2015-06-17 21:14:46 +00:00
|
|
|
int type = nd_region_to_nstype(nd_region);
|
2015-05-01 17:11:27 +00:00
|
|
|
|
2015-12-02 06:39:29 +00:00
|
|
|
if (!is_nd_pmem(dev) && a == &dev_attr_pfn_seed.attr)
|
|
|
|
return 0;
|
|
|
|
|
2016-03-11 18:15:36 +00:00
|
|
|
if (!is_nd_pmem(dev) && a == &dev_attr_dax_seed.attr)
|
|
|
|
return 0;
|
|
|
|
|
2015-06-17 21:14:46 +00:00
|
|
|
if (a != &dev_attr_set_cookie.attr
|
|
|
|
&& a != &dev_attr_available_size.attr)
|
2015-05-01 17:11:27 +00:00
|
|
|
return a->mode;
|
|
|
|
|
2015-06-17 21:14:46 +00:00
|
|
|
if ((type == ND_DEVICE_NAMESPACE_PMEM
|
|
|
|
|| type == ND_DEVICE_NAMESPACE_BLK)
|
|
|
|
&& a == &dev_attr_available_size.attr)
|
|
|
|
return a->mode;
|
|
|
|
else if (is_nd_pmem(dev) && nd_set)
|
|
|
|
return a->mode;
|
2015-05-01 17:11:27 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
struct attribute_group nd_region_attribute_group = {
|
|
|
|
.attrs = nd_region_attributes,
|
2015-05-01 17:11:27 +00:00
|
|
|
.is_visible = region_visible,
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
};
|
|
|
|
EXPORT_SYMBOL_GPL(nd_region_attribute_group);
|
|
|
|
|
2015-06-17 21:14:46 +00:00
|
|
|
u64 nd_region_interleave_set_cookie(struct nd_region *nd_region)
|
|
|
|
{
|
|
|
|
struct nd_interleave_set *nd_set = nd_region->nd_set;
|
|
|
|
|
|
|
|
if (nd_set)
|
|
|
|
return nd_set->cookie;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-19 23:04:21 +00:00
|
|
|
void nd_mapping_free_labels(struct nd_mapping *nd_mapping)
|
|
|
|
{
|
|
|
|
struct nd_label_ent *label_ent, *e;
|
|
|
|
|
2016-12-16 04:04:31 +00:00
|
|
|
lockdep_assert_held(&nd_mapping->lock);
|
2016-09-19 23:04:21 +00:00
|
|
|
list_for_each_entry_safe(label_ent, e, &nd_mapping->labels, list) {
|
|
|
|
list_del(&label_ent->list);
|
|
|
|
kfree(label_ent);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-01 17:11:27 +00:00
|
|
|
/*
|
|
|
|
* Upon successful probe/remove, take/release a reference on the
|
2015-06-25 08:20:04 +00:00
|
|
|
* associated interleave set (if present), and plant new btt + namespace
|
2015-06-25 08:21:02 +00:00
|
|
|
* seeds. Also, on the removal of a BLK region, notify the provider to
|
|
|
|
* disable the region.
|
2015-05-01 17:11:27 +00:00
|
|
|
*/
|
|
|
|
static void nd_region_notify_driver_action(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
struct device *dev, bool probe)
|
|
|
|
{
|
2015-06-25 08:20:04 +00:00
|
|
|
struct nd_region *nd_region;
|
|
|
|
|
2015-06-17 21:14:46 +00:00
|
|
|
if (!probe && (is_nd_pmem(dev) || is_nd_blk(dev))) {
|
2015-05-01 17:11:27 +00:00
|
|
|
int i;
|
|
|
|
|
2015-06-25 08:20:04 +00:00
|
|
|
nd_region = to_nd_region(dev);
|
2015-05-01 17:11:27 +00:00
|
|
|
for (i = 0; i < nd_region->ndr_mappings; i++) {
|
|
|
|
struct nd_mapping *nd_mapping = &nd_region->mapping[i];
|
2015-06-17 21:14:46 +00:00
|
|
|
struct nvdimm_drvdata *ndd = nd_mapping->ndd;
|
2015-05-01 17:11:27 +00:00
|
|
|
struct nvdimm *nvdimm = nd_mapping->nvdimm;
|
|
|
|
|
2016-09-19 23:04:21 +00:00
|
|
|
mutex_lock(&nd_mapping->lock);
|
|
|
|
nd_mapping_free_labels(nd_mapping);
|
|
|
|
mutex_unlock(&nd_mapping->lock);
|
|
|
|
|
2015-06-17 21:14:46 +00:00
|
|
|
put_ndd(ndd);
|
|
|
|
nd_mapping->ndd = NULL;
|
2015-06-25 08:21:02 +00:00
|
|
|
if (ndd)
|
|
|
|
atomic_dec(&nvdimm->busy);
|
2015-05-01 17:11:27 +00:00
|
|
|
}
|
2015-06-25 08:21:02 +00:00
|
|
|
|
|
|
|
if (is_nd_pmem(dev))
|
|
|
|
return;
|
2015-06-25 08:20:04 +00:00
|
|
|
}
|
2016-09-30 22:28:27 +00:00
|
|
|
if (dev->parent && (is_nd_blk(dev->parent) || is_nd_pmem(dev->parent))
|
|
|
|
&& probe) {
|
2015-06-25 08:20:04 +00:00
|
|
|
nd_region = to_nd_region(dev->parent);
|
2015-05-01 17:34:01 +00:00
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
if (nd_region->ns_seed == dev)
|
2016-09-30 22:28:27 +00:00
|
|
|
nd_region_create_ns_seed(nd_region);
|
2015-05-01 17:34:01 +00:00
|
|
|
nvdimm_bus_unlock(dev);
|
2015-05-01 17:11:27 +00:00
|
|
|
}
|
2015-06-25 08:20:04 +00:00
|
|
|
if (is_nd_btt(dev) && probe) {
|
2015-07-25 03:42:34 +00:00
|
|
|
struct nd_btt *nd_btt = to_nd_btt(dev);
|
|
|
|
|
2015-06-25 08:20:04 +00:00
|
|
|
nd_region = to_nd_region(dev->parent);
|
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
if (nd_region->btt_seed == dev)
|
|
|
|
nd_region_create_btt_seed(nd_region);
|
2016-09-30 22:28:27 +00:00
|
|
|
if (nd_region->ns_seed == &nd_btt->ndns->dev)
|
|
|
|
nd_region_create_ns_seed(nd_region);
|
2015-06-25 08:20:04 +00:00
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
}
|
2015-12-13 19:41:36 +00:00
|
|
|
if (is_nd_pfn(dev) && probe) {
|
2016-09-30 22:28:27 +00:00
|
|
|
struct nd_pfn *nd_pfn = to_nd_pfn(dev);
|
|
|
|
|
2015-12-13 19:41:36 +00:00
|
|
|
nd_region = to_nd_region(dev->parent);
|
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
if (nd_region->pfn_seed == dev)
|
|
|
|
nd_region_create_pfn_seed(nd_region);
|
2016-09-30 22:28:27 +00:00
|
|
|
if (nd_region->ns_seed == &nd_pfn->ndns->dev)
|
|
|
|
nd_region_create_ns_seed(nd_region);
|
2015-12-13 19:41:36 +00:00
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
}
|
2016-03-11 18:15:36 +00:00
|
|
|
if (is_nd_dax(dev) && probe) {
|
2016-09-30 22:28:27 +00:00
|
|
|
struct nd_dax *nd_dax = to_nd_dax(dev);
|
|
|
|
|
2016-03-11 18:15:36 +00:00
|
|
|
nd_region = to_nd_region(dev->parent);
|
|
|
|
nvdimm_bus_lock(dev);
|
|
|
|
if (nd_region->dax_seed == dev)
|
|
|
|
nd_region_create_dax_seed(nd_region);
|
2016-09-30 22:28:27 +00:00
|
|
|
if (nd_region->ns_seed == &nd_dax->nd_pfn.ndns->dev)
|
|
|
|
nd_region_create_ns_seed(nd_region);
|
2016-03-11 18:15:36 +00:00
|
|
|
nvdimm_bus_unlock(dev);
|
|
|
|
}
|
2015-05-01 17:11:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void nd_region_probe_success(struct nvdimm_bus *nvdimm_bus, struct device *dev)
|
|
|
|
{
|
|
|
|
nd_region_notify_driver_action(nvdimm_bus, dev, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
void nd_region_disable(struct nvdimm_bus *nvdimm_bus, struct device *dev)
|
|
|
|
{
|
|
|
|
nd_region_notify_driver_action(nvdimm_bus, dev, false);
|
|
|
|
}
|
|
|
|
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
static ssize_t mappingN(struct device *dev, char *buf, int n)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
struct nd_mapping *nd_mapping;
|
|
|
|
struct nvdimm *nvdimm;
|
|
|
|
|
|
|
|
if (n >= nd_region->ndr_mappings)
|
|
|
|
return -ENXIO;
|
|
|
|
nd_mapping = &nd_region->mapping[n];
|
|
|
|
nvdimm = nd_mapping->nvdimm;
|
|
|
|
|
|
|
|
return sprintf(buf, "%s,%llu,%llu\n", dev_name(&nvdimm->dev),
|
|
|
|
nd_mapping->start, nd_mapping->size);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define REGION_MAPPING(idx) \
|
|
|
|
static ssize_t mapping##idx##_show(struct device *dev, \
|
|
|
|
struct device_attribute *attr, char *buf) \
|
|
|
|
{ \
|
|
|
|
return mappingN(dev, buf, idx); \
|
|
|
|
} \
|
|
|
|
static DEVICE_ATTR_RO(mapping##idx)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 32 should be enough for a while, even in the presence of socket
|
|
|
|
* interleave a 32-way interleave set is a degenerate case.
|
|
|
|
*/
|
|
|
|
REGION_MAPPING(0);
|
|
|
|
REGION_MAPPING(1);
|
|
|
|
REGION_MAPPING(2);
|
|
|
|
REGION_MAPPING(3);
|
|
|
|
REGION_MAPPING(4);
|
|
|
|
REGION_MAPPING(5);
|
|
|
|
REGION_MAPPING(6);
|
|
|
|
REGION_MAPPING(7);
|
|
|
|
REGION_MAPPING(8);
|
|
|
|
REGION_MAPPING(9);
|
|
|
|
REGION_MAPPING(10);
|
|
|
|
REGION_MAPPING(11);
|
|
|
|
REGION_MAPPING(12);
|
|
|
|
REGION_MAPPING(13);
|
|
|
|
REGION_MAPPING(14);
|
|
|
|
REGION_MAPPING(15);
|
|
|
|
REGION_MAPPING(16);
|
|
|
|
REGION_MAPPING(17);
|
|
|
|
REGION_MAPPING(18);
|
|
|
|
REGION_MAPPING(19);
|
|
|
|
REGION_MAPPING(20);
|
|
|
|
REGION_MAPPING(21);
|
|
|
|
REGION_MAPPING(22);
|
|
|
|
REGION_MAPPING(23);
|
|
|
|
REGION_MAPPING(24);
|
|
|
|
REGION_MAPPING(25);
|
|
|
|
REGION_MAPPING(26);
|
|
|
|
REGION_MAPPING(27);
|
|
|
|
REGION_MAPPING(28);
|
|
|
|
REGION_MAPPING(29);
|
|
|
|
REGION_MAPPING(30);
|
|
|
|
REGION_MAPPING(31);
|
|
|
|
|
|
|
|
static umode_t mapping_visible(struct kobject *kobj, struct attribute *a, int n)
|
|
|
|
{
|
|
|
|
struct device *dev = container_of(kobj, struct device, kobj);
|
|
|
|
struct nd_region *nd_region = to_nd_region(dev);
|
|
|
|
|
|
|
|
if (n < nd_region->ndr_mappings)
|
|
|
|
return a->mode;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct attribute *mapping_attributes[] = {
|
|
|
|
&dev_attr_mapping0.attr,
|
|
|
|
&dev_attr_mapping1.attr,
|
|
|
|
&dev_attr_mapping2.attr,
|
|
|
|
&dev_attr_mapping3.attr,
|
|
|
|
&dev_attr_mapping4.attr,
|
|
|
|
&dev_attr_mapping5.attr,
|
|
|
|
&dev_attr_mapping6.attr,
|
|
|
|
&dev_attr_mapping7.attr,
|
|
|
|
&dev_attr_mapping8.attr,
|
|
|
|
&dev_attr_mapping9.attr,
|
|
|
|
&dev_attr_mapping10.attr,
|
|
|
|
&dev_attr_mapping11.attr,
|
|
|
|
&dev_attr_mapping12.attr,
|
|
|
|
&dev_attr_mapping13.attr,
|
|
|
|
&dev_attr_mapping14.attr,
|
|
|
|
&dev_attr_mapping15.attr,
|
|
|
|
&dev_attr_mapping16.attr,
|
|
|
|
&dev_attr_mapping17.attr,
|
|
|
|
&dev_attr_mapping18.attr,
|
|
|
|
&dev_attr_mapping19.attr,
|
|
|
|
&dev_attr_mapping20.attr,
|
|
|
|
&dev_attr_mapping21.attr,
|
|
|
|
&dev_attr_mapping22.attr,
|
|
|
|
&dev_attr_mapping23.attr,
|
|
|
|
&dev_attr_mapping24.attr,
|
|
|
|
&dev_attr_mapping25.attr,
|
|
|
|
&dev_attr_mapping26.attr,
|
|
|
|
&dev_attr_mapping27.attr,
|
|
|
|
&dev_attr_mapping28.attr,
|
|
|
|
&dev_attr_mapping29.attr,
|
|
|
|
&dev_attr_mapping30.attr,
|
|
|
|
&dev_attr_mapping31.attr,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct attribute_group nd_mapping_attribute_group = {
|
|
|
|
.is_visible = mapping_visible,
|
|
|
|
.attrs = mapping_attributes,
|
|
|
|
};
|
|
|
|
EXPORT_SYMBOL_GPL(nd_mapping_attribute_group);
|
|
|
|
|
2015-06-25 08:21:02 +00:00
|
|
|
int nd_blk_region_init(struct nd_region *nd_region)
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
{
|
2015-06-25 08:21:02 +00:00
|
|
|
struct device *dev = &nd_region->dev;
|
|
|
|
struct nvdimm_bus *nvdimm_bus = walk_to_nvdimm_bus(dev);
|
|
|
|
|
|
|
|
if (!is_nd_blk(dev))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (nd_region->ndr_mappings < 1) {
|
|
|
|
dev_err(dev, "invalid BLK region\n");
|
|
|
|
return -ENXIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
return to_nd_blk_region(dev)->enable(nvdimm_bus, dev);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
}
|
|
|
|
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
/**
|
|
|
|
* nd_region_acquire_lane - allocate and lock a lane
|
|
|
|
* @nd_region: region id and number of lanes possible
|
|
|
|
*
|
|
|
|
* A lane correlates to a BLK-data-window and/or a log slot in the BTT.
|
|
|
|
* We optimize for the common case where there are 256 lanes, one
|
|
|
|
* per-cpu. For larger systems we need to lock to share lanes. For now
|
|
|
|
* this implementation assumes the cost of maintaining an allocator for
|
|
|
|
* free lanes is on the order of the lock hold time, so it implements a
|
|
|
|
* static lane = cpu % num_lanes mapping.
|
|
|
|
*
|
|
|
|
* In the case of a BTT instance on top of a BLK namespace a lane may be
|
|
|
|
* acquired recursively. We lock on the first instance.
|
|
|
|
*
|
|
|
|
* In the case of a BTT instance on top of PMEM, we only acquire a lane
|
|
|
|
* for the BTT metadata updates.
|
|
|
|
*/
|
|
|
|
unsigned int nd_region_acquire_lane(struct nd_region *nd_region)
|
|
|
|
{
|
|
|
|
unsigned int cpu, lane;
|
|
|
|
|
|
|
|
cpu = get_cpu();
|
|
|
|
if (nd_region->num_lanes < nr_cpu_ids) {
|
|
|
|
struct nd_percpu_lane *ndl_lock, *ndl_count;
|
|
|
|
|
|
|
|
lane = cpu % nd_region->num_lanes;
|
|
|
|
ndl_count = per_cpu_ptr(nd_region->lane, cpu);
|
|
|
|
ndl_lock = per_cpu_ptr(nd_region->lane, lane);
|
|
|
|
if (ndl_count->count++ == 0)
|
|
|
|
spin_lock(&ndl_lock->lock);
|
|
|
|
} else
|
|
|
|
lane = cpu;
|
|
|
|
|
|
|
|
return lane;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nd_region_acquire_lane);
|
|
|
|
|
|
|
|
void nd_region_release_lane(struct nd_region *nd_region, unsigned int lane)
|
|
|
|
{
|
|
|
|
if (nd_region->num_lanes < nr_cpu_ids) {
|
|
|
|
unsigned int cpu = get_cpu();
|
|
|
|
struct nd_percpu_lane *ndl_lock, *ndl_count;
|
|
|
|
|
|
|
|
ndl_count = per_cpu_ptr(nd_region->lane, cpu);
|
|
|
|
ndl_lock = per_cpu_ptr(nd_region->lane, lane);
|
|
|
|
if (--ndl_count->count == 0)
|
|
|
|
spin_unlock(&ndl_lock->lock);
|
|
|
|
put_cpu();
|
|
|
|
}
|
|
|
|
put_cpu();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(nd_region_release_lane);
|
|
|
|
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
static struct nd_region *nd_region_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
struct nd_region_desc *ndr_desc, struct device_type *dev_type,
|
|
|
|
const char *caller)
|
|
|
|
{
|
|
|
|
struct nd_region *nd_region;
|
|
|
|
struct device *dev;
|
2015-06-25 08:21:02 +00:00
|
|
|
void *region_buf;
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
unsigned int i;
|
2015-06-24 00:08:34 +00:00
|
|
|
int ro = 0;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
|
|
|
|
for (i = 0; i < ndr_desc->num_mappings; i++) {
|
2016-09-19 23:38:50 +00:00
|
|
|
struct nd_mapping_desc *mapping = &ndr_desc->mapping[i];
|
|
|
|
struct nvdimm *nvdimm = mapping->nvdimm;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
|
2016-09-19 23:38:50 +00:00
|
|
|
if ((mapping->start | mapping->size) % SZ_4K) {
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
dev_err(&nvdimm_bus->dev, "%s: %s mapping%d is not 4K aligned\n",
|
|
|
|
caller, dev_name(&nvdimm->dev), i);
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
2015-06-24 00:08:34 +00:00
|
|
|
|
|
|
|
if (nvdimm->flags & NDD_UNARMED)
|
|
|
|
ro = 1;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
}
|
|
|
|
|
2015-06-25 08:21:02 +00:00
|
|
|
if (dev_type == &nd_blk_device_type) {
|
|
|
|
struct nd_blk_region_desc *ndbr_desc;
|
|
|
|
struct nd_blk_region *ndbr;
|
|
|
|
|
|
|
|
ndbr_desc = to_blk_region_desc(ndr_desc);
|
|
|
|
ndbr = kzalloc(sizeof(*ndbr) + sizeof(struct nd_mapping)
|
|
|
|
* ndr_desc->num_mappings,
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (ndbr) {
|
|
|
|
nd_region = &ndbr->nd_region;
|
|
|
|
ndbr->enable = ndbr_desc->enable;
|
|
|
|
ndbr->do_io = ndbr_desc->do_io;
|
|
|
|
}
|
|
|
|
region_buf = ndbr;
|
|
|
|
} else {
|
|
|
|
nd_region = kzalloc(sizeof(struct nd_region)
|
|
|
|
+ sizeof(struct nd_mapping)
|
|
|
|
* ndr_desc->num_mappings,
|
|
|
|
GFP_KERNEL);
|
|
|
|
region_buf = nd_region;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!region_buf)
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
return NULL;
|
|
|
|
nd_region->id = ida_simple_get(®ion_ida, 0, 0, GFP_KERNEL);
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
if (nd_region->id < 0)
|
|
|
|
goto err_id;
|
|
|
|
|
|
|
|
nd_region->lane = alloc_percpu(struct nd_percpu_lane);
|
|
|
|
if (!nd_region->lane)
|
|
|
|
goto err_percpu;
|
|
|
|
|
|
|
|
for (i = 0; i < nr_cpu_ids; i++) {
|
|
|
|
struct nd_percpu_lane *ndl;
|
|
|
|
|
|
|
|
ndl = per_cpu_ptr(nd_region->lane, i);
|
|
|
|
spin_lock_init(&ndl->lock);
|
|
|
|
ndl->count = 0;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < ndr_desc->num_mappings; i++) {
|
2016-09-19 23:38:50 +00:00
|
|
|
struct nd_mapping_desc *mapping = &ndr_desc->mapping[i];
|
|
|
|
struct nvdimm *nvdimm = mapping->nvdimm;
|
|
|
|
|
|
|
|
nd_region->mapping[i].nvdimm = nvdimm;
|
|
|
|
nd_region->mapping[i].start = mapping->start;
|
|
|
|
nd_region->mapping[i].size = mapping->size;
|
2016-09-19 23:04:21 +00:00
|
|
|
INIT_LIST_HEAD(&nd_region->mapping[i].labels);
|
|
|
|
mutex_init(&nd_region->mapping[i].lock);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
|
|
|
|
get_device(&nvdimm->dev);
|
|
|
|
}
|
|
|
|
nd_region->ndr_mappings = ndr_desc->num_mappings;
|
|
|
|
nd_region->provider_data = ndr_desc->provider_data;
|
2015-05-01 17:11:27 +00:00
|
|
|
nd_region->nd_set = ndr_desc->nd_set;
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
nd_region->num_lanes = ndr_desc->num_lanes;
|
2015-08-24 23:20:23 +00:00
|
|
|
nd_region->flags = ndr_desc->flags;
|
2015-06-24 00:08:34 +00:00
|
|
|
nd_region->ro = ro;
|
2015-06-19 18:18:33 +00:00
|
|
|
nd_region->numa_node = ndr_desc->numa_node;
|
2015-05-01 17:34:01 +00:00
|
|
|
ida_init(&nd_region->ns_ida);
|
2015-06-25 08:20:04 +00:00
|
|
|
ida_init(&nd_region->btt_ida);
|
2015-07-30 21:57:47 +00:00
|
|
|
ida_init(&nd_region->pfn_ida);
|
2016-03-11 18:15:36 +00:00
|
|
|
ida_init(&nd_region->dax_ida);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
dev = &nd_region->dev;
|
|
|
|
dev_set_name(dev, "region%d", nd_region->id);
|
|
|
|
dev->parent = &nvdimm_bus->dev;
|
|
|
|
dev->type = dev_type;
|
|
|
|
dev->groups = ndr_desc->attr_groups;
|
|
|
|
nd_region->ndr_size = resource_size(ndr_desc->res);
|
|
|
|
nd_region->ndr_start = ndr_desc->res->start;
|
|
|
|
nd_device_register(dev);
|
|
|
|
|
|
|
|
return nd_region;
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
|
|
|
|
err_percpu:
|
|
|
|
ida_simple_remove(®ion_ida, nd_region->id);
|
|
|
|
err_id:
|
2015-06-25 08:21:02 +00:00
|
|
|
kfree(region_buf);
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
return NULL;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
struct nd_region *nvdimm_pmem_region_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
struct nd_region_desc *ndr_desc)
|
|
|
|
{
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
ndr_desc->num_lanes = ND_MAX_LANES;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
return nd_region_create(nvdimm_bus, ndr_desc, &nd_pmem_device_type,
|
|
|
|
__func__);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(nvdimm_pmem_region_create);
|
|
|
|
|
|
|
|
struct nd_region *nvdimm_blk_region_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
struct nd_region_desc *ndr_desc)
|
|
|
|
{
|
|
|
|
if (ndr_desc->num_mappings > 1)
|
|
|
|
return NULL;
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
ndr_desc->num_lanes = min(ndr_desc->num_lanes, ND_MAX_LANES);
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
return nd_region_create(nvdimm_bus, ndr_desc, &nd_blk_device_type,
|
|
|
|
__func__);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(nvdimm_blk_region_create);
|
|
|
|
|
|
|
|
struct nd_region *nvdimm_volatile_region_create(struct nvdimm_bus *nvdimm_bus,
|
|
|
|
struct nd_region_desc *ndr_desc)
|
|
|
|
{
|
nd_btt: atomic sector updates
BTT stands for Block Translation Table, and is a way to provide power
fail sector atomicity semantics for block devices that have the ability
to perform byte granularity IO. It relies on the capability of libnvdimm
namespace devices to do byte aligned IO.
The BTT works as a stacked blocked device, and reserves a chunk of space
from the backing device for its accounting metadata. It is a bio-based
driver because all IO is done synchronously, and there is no queuing or
asynchronous completions at either the device or the driver level.
The BTT uses 'lanes' to index into various 'on-disk' data structures,
and lanes also act as a synchronization mechanism in case there are more
CPUs than available lanes. We did a comparison between two lane lock
strategies - first where we kept an atomic counter around that tracked
which was the last lane that was used, and 'our' lane was determined by
atomically incrementing that. That way, for the nr_cpus > nr_lanes case,
theoretically, no CPU would be blocked waiting for a lane. The other
strategy was to use the cpu number we're scheduled on to and hash it to
a lane number. Theoretically, this could block an IO that could've
otherwise run using a different, free lane. But some fio workloads
showed that the direct cpu -> lane hash performed faster than tracking
'last lane' - my reasoning is the cache thrash caused by moving the
atomic variable made that approach slower than simply waiting out the
in-progress IO. This supports the conclusion that the driver can be a
very simple bio-based one that does synchronous IOs instead of queuing.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boaz Harrosh <boaz@plexistor.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Neil Brown <neilb@suse.de>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
[jmoyer: fix nmi watchdog timeout in btt_map_init]
[jmoyer: move btt initialization to module load path]
[jmoyer: fix memory leak in the btt initialization path]
[jmoyer: Don't overwrite corrupted arenas]
Signed-off-by: Vishal Verma <vishal.l.verma@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-25 08:20:32 +00:00
|
|
|
ndr_desc->num_lanes = ND_MAX_LANES;
|
libnvdimm, nfit: regions (block-data-window, persistent memory, volatile memory)
A "region" device represents the maximum capacity of a BLK range (mmio
block-data-window(s)), or a PMEM range (DAX-capable persistent memory or
volatile memory), without regard for aliasing. Aliasing, in the
dimm-local address space (DPA), is resolved by metadata on a dimm to
designate which exclusive interface will access the aliased DPA ranges.
Support for the per-dimm metadata/label arrvies is in a subsequent
patch.
The name format of "region" devices is "regionN" where, like dimms, N is
a global ida index assigned at discovery time. This id is not reliable
across reboots nor in the presence of hotplug. Look to attributes of
the region or static id-data of the sub-namespace to generate a
persistent name. However, if the platform configuration does not change
it is reasonable to expect the same region id to be assigned at the next
boot.
"region"s have 2 generic attributes "size", and "mapping"s where:
- size: the BLK accessible capacity or the span of the
system physical address range in the case of PMEM.
- mappingN: a tuple describing a dimm's contribution to the region's
capacity in the format (<nmemX>,<dpa>,<size>). For a PMEM-region
there will be at least one mapping per dimm in the interleave set. For
a BLK-region there is only "mapping0" listing the starting DPA of the
BLK-region and the available DPA capacity of that space (matches "size"
above).
The max number of mappings per "region" is hard coded per the
constraints of sysfs attribute groups. That said the number of mappings
per region should never exceed the maximum number of possible dimms in
the system. If the current number turns out to not be enough then the
"mappings" attribute clarifies how many there are supposed to be. "32
should be enough for anybody...".
Cc: Neil Brown <neilb@suse.de>
Cc: <linux-acpi@vger.kernel.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-06-10 00:13:14 +00:00
|
|
|
return nd_region_create(nvdimm_bus, ndr_desc, &nd_volatile_device_type,
|
|
|
|
__func__);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(nvdimm_volatile_region_create);
|
2016-05-18 03:24:16 +00:00
|
|
|
|
2016-07-08 02:44:50 +00:00
|
|
|
/**
|
|
|
|
* nvdimm_flush - flush any posted write queues between the cpu and pmem media
|
|
|
|
* @nd_region: blk or interleaved pmem region
|
|
|
|
*/
|
|
|
|
void nvdimm_flush(struct nd_region *nd_region)
|
|
|
|
{
|
|
|
|
struct nd_region_data *ndrd = dev_get_drvdata(&nd_region->dev);
|
2016-05-27 16:23:01 +00:00
|
|
|
int i, idx;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to encourage some diversity in flush hint addresses
|
|
|
|
* across cpus assuming a limited number of flush hints.
|
|
|
|
*/
|
|
|
|
idx = this_cpu_read(flush_idx);
|
|
|
|
idx = this_cpu_add_return(flush_idx, hash_32(current->pid + idx, 8));
|
2016-07-08 02:44:50 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The first wmb() is needed to 'sfence' all previous writes
|
|
|
|
* such that they are architecturally visible for the platform
|
|
|
|
* buffer flush. Note that we've already arranged for pmem
|
|
|
|
* writes to avoid the cache via arch_memcpy_to_pmem(). The
|
|
|
|
* final wmb() ensures ordering for the NVDIMM flush write.
|
|
|
|
*/
|
|
|
|
wmb();
|
|
|
|
for (i = 0; i < nd_region->ndr_mappings; i++)
|
2016-09-24 00:53:52 +00:00
|
|
|
if (ndrd_get_flush_wpq(ndrd, i, 0))
|
|
|
|
writeq(1, ndrd_get_flush_wpq(ndrd, i, idx));
|
2016-07-08 02:44:50 +00:00
|
|
|
wmb();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(nvdimm_flush);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* nvdimm_has_flush - determine write flushing requirements
|
|
|
|
* @nd_region: blk or interleaved pmem region
|
|
|
|
*
|
|
|
|
* Returns 1 if writes require flushing
|
|
|
|
* Returns 0 if writes do not require flushing
|
|
|
|
* Returns -ENXIO if flushing capability can not be determined
|
|
|
|
*/
|
|
|
|
int nvdimm_has_flush(struct nd_region *nd_region)
|
|
|
|
{
|
|
|
|
struct nd_region_data *ndrd = dev_get_drvdata(&nd_region->dev);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* no nvdimm == flushing capability unknown */
|
|
|
|
if (nd_region->ndr_mappings == 0)
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
for (i = 0; i < nd_region->ndr_mappings; i++)
|
|
|
|
/* flush hints present, flushing required */
|
2016-09-24 00:53:52 +00:00
|
|
|
if (ndrd_get_flush_wpq(ndrd, i, 0))
|
2016-07-08 02:44:50 +00:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The platform defines dimm devices without hints, assume
|
|
|
|
* platform persistence mechanism like ADR
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(nvdimm_has_flush);
|
|
|
|
|
2016-05-18 03:24:16 +00:00
|
|
|
void __exit nd_region_devs_exit(void)
|
|
|
|
{
|
|
|
|
ida_destroy(®ion_ida);
|
|
|
|
}
|