2019-05-29 22:18:09 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2015-06-01 02:41:48 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright(c) 2013-2015 Intel Corporation. All rights reserved.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef __ND_H__
|
|
|
|
|
#define __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 08:13:14 +08:00
|
|
|
#include <linux/libnvdimm.h>
|
2016-03-22 15:22:16 +08:00
|
|
|
#include <linux/badblocks.h>
|
2015-05-17 00:28:53 +08:00
|
|
|
#include <linux/blkdev.h>
|
2015-06-01 02:41:48 +08:00
|
|
|
#include <linux/device.h>
|
|
|
|
|
#include <linux/mutex.h>
|
|
|
|
|
#include <linux/ndctl.h>
|
2015-06-18 05:14:46 +08:00
|
|
|
#include <linux/types.h>
|
2016-02-19 02:29:49 +08:00
|
|
|
#include <linux/nd.h>
|
2015-06-10 04:09:36 +08:00
|
|
|
#include "label.h"
|
2015-06-01 02:41:48 +08:00
|
|
|
|
2015-06-25 16:20:04 +08:00
|
|
|
enum {
|
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 16:20:32 +08:00
|
|
|
/*
|
|
|
|
|
* Limits the maximum number of block apertures a dimm can
|
|
|
|
|
* support and is an input to the geometry/on-disk-format of a
|
|
|
|
|
* BTT instance
|
|
|
|
|
*/
|
|
|
|
|
ND_MAX_LANES = 256,
|
2015-06-25 16:22:39 +08:00
|
|
|
INT_LBASIZE_ALIGNMENT = 64,
|
2017-05-11 05:01:30 +08:00
|
|
|
NVDIMM_IO_ATOMIC = 1,
|
2015-06-25 16:20:04 +08:00
|
|
|
};
|
|
|
|
|
|
2015-06-01 02:41:48 +08:00
|
|
|
struct nvdimm_drvdata {
|
|
|
|
|
struct device *dev;
|
2017-08-30 09:28:18 +08:00
|
|
|
int nslabel_size;
|
2015-06-01 02:41:48 +08:00
|
|
|
struct nd_cmd_get_config_size nsarea;
|
|
|
|
|
void *data;
|
2015-06-10 04:09:36 +08:00
|
|
|
int ns_current, ns_next;
|
|
|
|
|
struct resource dpa;
|
2015-06-18 05:14:46 +08:00
|
|
|
struct kref kref;
|
2015-06-01 02:41:48 +08:00
|
|
|
};
|
|
|
|
|
|
2016-06-08 08:00:04 +08:00
|
|
|
struct nd_region_data {
|
|
|
|
|
int ns_count;
|
|
|
|
|
int ns_active;
|
2016-09-24 08:53:52 +08:00
|
|
|
unsigned int hints_shift;
|
2020-03-20 07:09:37 +08:00
|
|
|
void __iomem *flush_wpq[];
|
2015-06-01 03:02:11 +08:00
|
|
|
};
|
|
|
|
|
|
2016-09-24 08:53:52 +08:00
|
|
|
static inline void __iomem *ndrd_get_flush_wpq(struct nd_region_data *ndrd,
|
|
|
|
|
int dimm, int hint)
|
|
|
|
|
{
|
|
|
|
|
unsigned int num = 1 << ndrd->hints_shift;
|
|
|
|
|
unsigned int mask = num - 1;
|
|
|
|
|
|
|
|
|
|
return ndrd->flush_wpq[dimm * num + (hint & mask)];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void ndrd_set_flush_wpq(struct nd_region_data *ndrd, int dimm,
|
|
|
|
|
int hint, void __iomem *flush)
|
|
|
|
|
{
|
|
|
|
|
unsigned int num = 1 << ndrd->hints_shift;
|
|
|
|
|
unsigned int mask = num - 1;
|
|
|
|
|
|
|
|
|
|
ndrd->flush_wpq[dimm * num + (hint & mask)] = flush;
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-10 04:09:36 +08:00
|
|
|
static inline struct nd_namespace_index *to_namespace_index(
|
|
|
|
|
struct nvdimm_drvdata *ndd, int i)
|
|
|
|
|
{
|
|
|
|
|
if (i < 0)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
return ndd->data + sizeof_namespace_index(ndd) * i;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct nd_namespace_index *to_current_namespace_index(
|
|
|
|
|
struct nvdimm_drvdata *ndd)
|
|
|
|
|
{
|
|
|
|
|
return to_namespace_index(ndd, ndd->ns_current);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct nd_namespace_index *to_next_namespace_index(
|
|
|
|
|
struct nvdimm_drvdata *ndd)
|
|
|
|
|
{
|
|
|
|
|
return to_namespace_index(ndd, ndd->ns_next);
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-03 17:30:43 +08:00
|
|
|
unsigned sizeof_namespace_label(struct nvdimm_drvdata *ndd);
|
|
|
|
|
|
|
|
|
|
#define namespace_label_has(ndd, field) \
|
|
|
|
|
(offsetof(struct nd_namespace_label, field) \
|
|
|
|
|
< sizeof_namespace_label(ndd))
|
|
|
|
|
|
2015-06-10 04:09:36 +08:00
|
|
|
#define nd_dbg_dpa(r, d, res, fmt, arg...) \
|
|
|
|
|
dev_dbg((r) ? &(r)->dev : (d)->dev, "%s: %.13s: %#llx @ %#llx " fmt, \
|
|
|
|
|
(r) ? dev_name((d)->dev) : "", res ? res->name : "null", \
|
|
|
|
|
(unsigned long long) (res ? resource_size(res) : 0), \
|
|
|
|
|
(unsigned long long) (res ? res->start : 0), ##arg)
|
|
|
|
|
|
2015-06-18 05:14:46 +08:00
|
|
|
#define for_each_dpa_resource(ndd, res) \
|
|
|
|
|
for (res = (ndd)->dpa.child; res; res = res->sibling)
|
|
|
|
|
|
2015-06-10 04:09:36 +08:00
|
|
|
#define for_each_dpa_resource_safe(ndd, res, next) \
|
|
|
|
|
for (res = (ndd)->dpa.child, next = res ? res->sibling : NULL; \
|
|
|
|
|
res; res = next, next = next ? next->sibling : 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 16:20:32 +08:00
|
|
|
struct nd_percpu_lane {
|
|
|
|
|
int count;
|
|
|
|
|
spinlock_t lock;
|
|
|
|
|
};
|
|
|
|
|
|
2019-05-01 12:51:21 +08:00
|
|
|
enum nd_label_flags {
|
|
|
|
|
ND_LABEL_REAP,
|
|
|
|
|
};
|
2016-09-20 07:04:21 +08:00
|
|
|
struct nd_label_ent {
|
|
|
|
|
struct list_head list;
|
2019-05-01 12:51:21 +08:00
|
|
|
unsigned long flags;
|
2016-09-20 07:04:21 +08:00
|
|
|
struct nd_namespace_label *label;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum nd_mapping_lock_class {
|
|
|
|
|
ND_MAPPING_CLASS0,
|
|
|
|
|
ND_MAPPING_UUID_SCAN,
|
|
|
|
|
};
|
|
|
|
|
|
2016-09-20 07:38:50 +08:00
|
|
|
struct nd_mapping {
|
|
|
|
|
struct nvdimm *nvdimm;
|
|
|
|
|
u64 start;
|
|
|
|
|
u64 size;
|
2017-08-05 08:20:16 +08:00
|
|
|
int position;
|
2016-09-20 07:04:21 +08:00
|
|
|
struct list_head labels;
|
|
|
|
|
struct mutex lock;
|
2016-09-20 07:38:50 +08:00
|
|
|
/*
|
|
|
|
|
* @ndd is for private use at region enable / disable time for
|
|
|
|
|
* get_ndd() + put_ndd(), all other nd_mapping to ndd
|
|
|
|
|
* conversions use to_ndd() which respects enabled state of the
|
|
|
|
|
* nvdimm.
|
|
|
|
|
*/
|
|
|
|
|
struct nvdimm_drvdata *ndd;
|
|
|
|
|
};
|
|
|
|
|
|
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 08:13:14 +08:00
|
|
|
struct nd_region {
|
|
|
|
|
struct device dev;
|
2015-05-02 01:34:01 +08:00
|
|
|
struct ida ns_ida;
|
2015-06-25 16:20:04 +08:00
|
|
|
struct ida btt_ida;
|
2015-07-31 05:57:47 +08:00
|
|
|
struct ida pfn_ida;
|
2016-03-12 02:15:36 +08:00
|
|
|
struct ida dax_ida;
|
2015-08-25 07:20:23 +08:00
|
|
|
unsigned long flags;
|
2015-06-18 05:14:46 +08:00
|
|
|
struct device *ns_seed;
|
2015-06-25 16:20:04 +08:00
|
|
|
struct device *btt_seed;
|
2015-07-31 05:57:47 +08:00
|
|
|
struct device *pfn_seed;
|
2016-03-12 02:15:36 +08:00
|
|
|
struct device *dax_seed;
|
2020-01-31 04:06:23 +08:00
|
|
|
unsigned long align;
|
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 08:13:14 +08:00
|
|
|
u16 ndr_mappings;
|
|
|
|
|
u64 ndr_size;
|
|
|
|
|
u64 ndr_start;
|
2018-11-10 04:43:07 +08:00
|
|
|
int id, num_lanes, ro, numa_node, target_node;
|
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 08:13:14 +08:00
|
|
|
void *provider_data;
|
2017-06-13 06:25:11 +08:00
|
|
|
struct kernfs_node *bb_state;
|
2017-04-08 06:33:20 +08:00
|
|
|
struct badblocks bb;
|
2015-05-02 01:11:27 +08:00
|
|
|
struct nd_interleave_set *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 16:20:32 +08:00
|
|
|
struct nd_percpu_lane __percpu *lane;
|
2019-07-05 22:03:22 +08:00
|
|
|
int (*flush)(struct nd_region *nd_region, struct bio *bio);
|
2020-03-20 07:09:37 +08:00
|
|
|
struct nd_mapping mapping[];
|
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 08:13:14 +08:00
|
|
|
};
|
|
|
|
|
|
2015-06-25 16:21:02 +08:00
|
|
|
struct nd_blk_region {
|
|
|
|
|
int (*enable)(struct nvdimm_bus *nvdimm_bus, struct device *dev);
|
|
|
|
|
int (*do_io)(struct nd_blk_region *ndbr, resource_size_t dpa,
|
|
|
|
|
void *iobuf, u64 len, int rw);
|
|
|
|
|
void *blk_provider_data;
|
|
|
|
|
struct nd_region nd_region;
|
|
|
|
|
};
|
|
|
|
|
|
2015-06-10 04:09:36 +08:00
|
|
|
/*
|
|
|
|
|
* Lookup next in the repeating sequence of 01, 10, and 11.
|
|
|
|
|
*/
|
|
|
|
|
static inline unsigned nd_inc_seq(unsigned seq)
|
|
|
|
|
{
|
|
|
|
|
static const unsigned next[] = { 0, 2, 3, 1 };
|
|
|
|
|
|
|
|
|
|
return next[seq & 3];
|
|
|
|
|
}
|
2015-05-31 00:36:02 +08: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 16:20:32 +08:00
|
|
|
struct btt;
|
2015-06-25 16:20:04 +08:00
|
|
|
struct nd_btt {
|
|
|
|
|
struct device dev;
|
|
|
|
|
struct nd_namespace_common *ndns;
|
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 16:20:32 +08:00
|
|
|
struct btt *btt;
|
2015-06-25 16:20:04 +08:00
|
|
|
unsigned long lbasize;
|
2016-07-28 06:38:59 +08:00
|
|
|
u64 size;
|
2015-06-25 16:20:04 +08:00
|
|
|
u8 *uuid;
|
|
|
|
|
int id;
|
2017-06-29 04:25:00 +08:00
|
|
|
int initial_offset;
|
|
|
|
|
u16 version_major;
|
|
|
|
|
u16 version_minor;
|
2015-06-25 16:20:04 +08:00
|
|
|
};
|
|
|
|
|
|
2015-07-31 05:57:47 +08:00
|
|
|
enum nd_pfn_mode {
|
|
|
|
|
PFN_MODE_NONE,
|
|
|
|
|
PFN_MODE_RAM,
|
|
|
|
|
PFN_MODE_PMEM,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct nd_pfn {
|
|
|
|
|
int id;
|
|
|
|
|
u8 *uuid;
|
|
|
|
|
struct device dev;
|
2015-12-11 06:45:23 +08:00
|
|
|
unsigned long align;
|
2015-07-31 05:57:47 +08:00
|
|
|
unsigned long npfns;
|
|
|
|
|
enum nd_pfn_mode mode;
|
|
|
|
|
struct nd_pfn_sb *pfn_sb;
|
|
|
|
|
struct nd_namespace_common *ndns;
|
|
|
|
|
};
|
|
|
|
|
|
2016-03-12 02:15:36 +08:00
|
|
|
struct nd_dax {
|
|
|
|
|
struct nd_pfn nd_pfn;
|
|
|
|
|
};
|
|
|
|
|
|
2019-10-31 18:57:41 +08:00
|
|
|
static inline u32 nd_info_block_reserve(void)
|
|
|
|
|
{
|
|
|
|
|
return ALIGN(SZ_8K, PAGE_SIZE);
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-01 02:41:48 +08:00
|
|
|
enum nd_async_mode {
|
|
|
|
|
ND_SYNC,
|
|
|
|
|
ND_ASYNC,
|
|
|
|
|
};
|
|
|
|
|
|
2015-06-25 16:21:52 +08:00
|
|
|
int nd_integrity_init(struct gendisk *disk, unsigned long meta_size);
|
2015-06-18 05:14:46 +08:00
|
|
|
void wait_nvdimm_bus_probe_idle(struct device *dev);
|
2015-06-01 02:41:48 +08:00
|
|
|
void nd_device_register(struct device *dev);
|
|
|
|
|
void nd_device_unregister(struct device *dev, enum nd_async_mode mode);
|
2016-02-19 02:29:49 +08:00
|
|
|
void nd_device_notify(struct device *dev, enum nvdimm_event event);
|
2015-06-18 05:14:46 +08:00
|
|
|
int nd_uuid_store(struct device *dev, u8 **uuid_out, const char *buf,
|
|
|
|
|
size_t len);
|
2017-08-12 08:36:54 +08:00
|
|
|
ssize_t nd_size_select_show(unsigned long current_size,
|
2015-05-02 01:34:01 +08:00
|
|
|
const unsigned long *supported, char *buf);
|
2017-08-12 08:36:54 +08:00
|
|
|
ssize_t nd_size_select_store(struct device *dev, const char *buf,
|
|
|
|
|
unsigned long *current_size, const unsigned long *supported);
|
2015-06-01 02:41:48 +08:00
|
|
|
int __init nvdimm_init(void);
|
2015-06-01 03:02:11 +08:00
|
|
|
int __init nd_region_init(void);
|
2017-06-04 09:18:39 +08:00
|
|
|
int __init nd_label_init(void);
|
2015-06-01 02:41:48 +08:00
|
|
|
void nvdimm_exit(void);
|
2015-06-01 03:02:11 +08:00
|
|
|
void nd_region_exit(void);
|
2015-06-18 05:14:46 +08:00
|
|
|
struct nvdimm;
|
2019-11-13 09:00:24 +08:00
|
|
|
extern const struct attribute_group nd_device_attribute_group;
|
2019-11-20 01:51:54 +08:00
|
|
|
extern const struct attribute_group nd_numa_attribute_group;
|
2019-11-13 09:08:56 +08:00
|
|
|
extern const struct attribute_group *nvdimm_bus_attribute_groups[];
|
2015-06-18 05:14:46 +08:00
|
|
|
struct nvdimm_drvdata *to_ndd(struct nd_mapping *nd_mapping);
|
2016-08-17 03:08:40 +08:00
|
|
|
int nvdimm_check_config_data(struct device *dev);
|
2015-06-01 02:41:48 +08:00
|
|
|
int nvdimm_init_nsarea(struct nvdimm_drvdata *ndd);
|
|
|
|
|
int nvdimm_init_config_data(struct nvdimm_drvdata *ndd);
|
2018-10-11 07:39:20 +08:00
|
|
|
int nvdimm_get_config_data(struct nvdimm_drvdata *ndd, void *buf,
|
|
|
|
|
size_t offset, size_t len);
|
2015-05-31 00:36:02 +08:00
|
|
|
int nvdimm_set_config_data(struct nvdimm_drvdata *ndd, size_t offset,
|
|
|
|
|
void *buf, size_t len);
|
2016-03-08 23:16:07 +08:00
|
|
|
long nvdimm_clear_poison(struct device *dev, phys_addr_t phys,
|
|
|
|
|
unsigned int len);
|
2020-01-31 04:06:18 +08:00
|
|
|
void nvdimm_set_labeling(struct device *dev);
|
2017-05-05 05:01:24 +08:00
|
|
|
void nvdimm_set_locked(struct device *dev);
|
2017-09-26 02:01:31 +08:00
|
|
|
void nvdimm_clear_locked(struct device *dev);
|
2019-01-20 00:45:56 +08:00
|
|
|
int nvdimm_security_setup_events(struct device *dev);
|
2018-12-07 04:40:01 +08:00
|
|
|
#if IS_ENABLED(CONFIG_NVDIMM_KEYS)
|
|
|
|
|
int nvdimm_security_unlock(struct device *dev);
|
|
|
|
|
#else
|
|
|
|
|
static inline int nvdimm_security_unlock(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2015-06-25 16:20:04 +08:00
|
|
|
struct nd_btt *to_nd_btt(struct device *dev);
|
2015-07-31 05:57:47 +08:00
|
|
|
|
|
|
|
|
struct nd_gen_sb {
|
|
|
|
|
char reserved[SZ_4K - 8];
|
|
|
|
|
__le64 checksum;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
u64 nd_sb_checksum(struct nd_gen_sb *sb);
|
2015-06-25 16:20:04 +08:00
|
|
|
#if IS_ENABLED(CONFIG_BTT)
|
2016-03-22 15:22:16 +08:00
|
|
|
int nd_btt_probe(struct device *dev, struct nd_namespace_common *ndns);
|
2015-06-25 16:20:04 +08:00
|
|
|
bool is_nd_btt(struct device *dev);
|
|
|
|
|
struct device *nd_btt_create(struct nd_region *nd_region);
|
|
|
|
|
#else
|
2016-03-18 09:23:09 +08:00
|
|
|
static inline int nd_btt_probe(struct device *dev,
|
2016-03-22 15:22:16 +08:00
|
|
|
struct nd_namespace_common *ndns)
|
2015-06-25 16:20:04 +08:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool is_nd_btt(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct device *nd_btt_create(struct nd_region *nd_region)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2015-07-31 05:57:47 +08:00
|
|
|
#endif
|
2015-06-25 16:20:04 +08:00
|
|
|
|
2015-07-31 05:57:47 +08:00
|
|
|
struct nd_pfn *to_nd_pfn(struct device *dev);
|
|
|
|
|
#if IS_ENABLED(CONFIG_NVDIMM_PFN)
|
2017-06-27 17:56:33 +08:00
|
|
|
|
libnvdimm/dax: Pick the right alignment default when creating dax devices
Allow arch to provide the supported alignments and use hugepage alignment only
if we support hugepage. Right now we depend on compile time configs whereas this
patch switch this to runtime discovery.
Architectures like ppc64 can have THP enabled in code, but then can have
hugepage size disabled by the hypervisor. This allows us to create dax devices
with PAGE_SIZE alignment in this case.
Existing dax namespace with alignment larger than PAGE_SIZE will fail to
initialize in this specific case. We still allow fsdax namespace initialization.
With respect to identifying whether to enable hugepage fault for a dax device,
if THP is enabled during compile, we default to taking hugepage fault and in dax
fault handler if we find the fault size > alignment we retry with PAGE_SIZE
fault size.
This also addresses the below failure scenario on ppc64
ndctl create-namespace --mode=devdax | grep align
"align":16777216,
"align":16777216
cat /sys/devices/ndbus0/region0/dax0.0/supported_alignments
65536 16777216
daxio.static-debug -z -o /dev/dax0.0
Bus error (core dumped)
$ dmesg | tail
lpar: Failed hash pte insert with error -4
hash-mmu: mm: Hashing failure ! EA=0x7fff17000000 access=0x8000000000000006 current=daxio
hash-mmu: trap=0x300 vsid=0x22cb7a3 ssize=1 base psize=2 psize 10 pte=0xc000000501002b86
daxio[3860]: bus error (7) at 7fff17000000 nip 7fff973c007c lr 7fff973bff34 code 2 in libpmem.so.1.0.0[7fff973b0000+20000]
daxio[3860]: code: 792945e4 7d494b78 e95f0098 7d494b78 f93f00a0 4800012c e93f0088 f93f0120
daxio[3860]: code: e93f00a0 f93f0128 e93f0120 e95f0128 <f9490000> e93f0088 39290008 f93f0110
The failure was due to guest kernel using wrong page size.
The namespaces created with 16M alignment will appear as below on a config with
16M page size disabled.
$ ndctl list -Ni
[
{
"dev":"namespace0.1",
"mode":"fsdax",
"map":"dev",
"size":5351931904,
"uuid":"fc6e9667-461a-4718-82b4-69b24570bddb",
"align":16777216,
"blockdev":"pmem0.1",
"supported_alignments":[
65536
]
},
{
"dev":"namespace0.0",
"mode":"fsdax", <==== devdax 16M alignment marked disabled.
"map":"mem",
"size":5368709120,
"uuid":"a4bdf81a-f2ee-4bc6-91db-7b87eddd0484",
"state":"disabled"
}
]
Cc: linux-mm@kvack.org
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Link: https://lore.kernel.org/r/20190905154603.10349-8-aneesh.kumar@linux.ibm.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2019-09-05 23:46:03 +08:00
|
|
|
#define MAX_NVDIMM_ALIGN 4
|
2017-06-27 17:56:33 +08:00
|
|
|
|
2016-03-22 15:22:16 +08:00
|
|
|
int nd_pfn_probe(struct device *dev, struct nd_namespace_common *ndns);
|
2015-07-31 05:57:47 +08:00
|
|
|
bool is_nd_pfn(struct device *dev);
|
|
|
|
|
struct device *nd_pfn_create(struct nd_region *nd_region);
|
2016-03-12 02:15:36 +08:00
|
|
|
struct device *nd_pfn_devinit(struct nd_pfn *nd_pfn,
|
|
|
|
|
struct nd_namespace_common *ndns);
|
2016-05-19 05:50:12 +08:00
|
|
|
int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig);
|
2019-11-07 11:56:41 +08:00
|
|
|
extern const struct attribute_group *nd_pfn_attribute_groups[];
|
2015-07-31 05:57:47 +08:00
|
|
|
#else
|
2016-03-22 15:22:16 +08:00
|
|
|
static inline int nd_pfn_probe(struct device *dev,
|
|
|
|
|
struct nd_namespace_common *ndns)
|
2015-07-31 05:57:47 +08:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool is_nd_pfn(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct device *nd_pfn_create(struct nd_region *nd_region)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2015-08-01 14:16:37 +08:00
|
|
|
|
2016-05-19 05:50:12 +08:00
|
|
|
static inline int nd_pfn_validate(struct nd_pfn *nd_pfn, const char *sig)
|
2015-08-01 14:16:37 +08:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
2015-06-25 16:20:04 +08:00
|
|
|
#endif
|
2015-07-31 05:57:47 +08:00
|
|
|
|
2016-03-12 02:15:36 +08:00
|
|
|
struct nd_dax *to_nd_dax(struct device *dev);
|
|
|
|
|
#if IS_ENABLED(CONFIG_NVDIMM_DAX)
|
2016-05-19 05:50:12 +08:00
|
|
|
int nd_dax_probe(struct device *dev, struct nd_namespace_common *ndns);
|
2016-03-12 02:15:36 +08:00
|
|
|
bool is_nd_dax(struct device *dev);
|
|
|
|
|
struct device *nd_dax_create(struct nd_region *nd_region);
|
|
|
|
|
#else
|
2016-05-19 05:50:12 +08:00
|
|
|
static inline int nd_dax_probe(struct device *dev,
|
|
|
|
|
struct nd_namespace_common *ndns)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-12 02:15:36 +08:00
|
|
|
static inline bool is_nd_dax(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct device *nd_dax_create(struct nd_region *nd_region)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-06-01 03:02:11 +08:00
|
|
|
int nd_region_to_nstype(struct nd_region *nd_region);
|
|
|
|
|
int nd_region_register_namespaces(struct nd_region *nd_region, int *err);
|
2017-06-04 09:59:15 +08:00
|
|
|
u64 nd_region_interleave_set_cookie(struct nd_region *nd_region,
|
|
|
|
|
struct nd_namespace_index *nsindex);
|
2017-03-01 10:32:48 +08:00
|
|
|
u64 nd_region_interleave_set_altcookie(struct nd_region *nd_region);
|
2015-06-01 03:02:11 +08:00
|
|
|
void nvdimm_bus_lock(struct device *dev);
|
|
|
|
|
void nvdimm_bus_unlock(struct device *dev);
|
|
|
|
|
bool is_nvdimm_bus_locked(struct device *dev);
|
2020-09-01 23:57:47 +08:00
|
|
|
void nvdimm_check_and_set_ro(struct gendisk *disk);
|
2015-06-18 05:14:46 +08:00
|
|
|
void nvdimm_drvdata_release(struct kref *kref);
|
|
|
|
|
void put_ndd(struct nvdimm_drvdata *ndd);
|
2015-06-10 04:09:36 +08:00
|
|
|
int nd_label_reserve_dpa(struct nvdimm_drvdata *ndd);
|
|
|
|
|
void nvdimm_free_dpa(struct nvdimm_drvdata *ndd, struct resource *res);
|
|
|
|
|
struct resource *nvdimm_allocate_dpa(struct nvdimm_drvdata *ndd,
|
|
|
|
|
struct nd_label_id *label_id, resource_size_t start,
|
|
|
|
|
resource_size_t n);
|
2015-06-25 16:20:04 +08:00
|
|
|
resource_size_t nvdimm_namespace_capacity(struct nd_namespace_common *ndns);
|
2018-06-14 00:08:36 +08:00
|
|
|
bool nvdimm_namespace_locked(struct nd_namespace_common *ndns);
|
2015-06-25 16:20:04 +08:00
|
|
|
struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *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 16:20:32 +08:00
|
|
|
int nvdimm_namespace_attach_btt(struct nd_namespace_common *ndns);
|
2016-03-16 07:41:04 +08:00
|
|
|
int nvdimm_namespace_detach_btt(struct nd_btt *nd_btt);
|
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 16:20:32 +08:00
|
|
|
const char *nvdimm_namespace_disk_name(struct nd_namespace_common *ndns,
|
|
|
|
|
char *name);
|
2017-06-04 11:12:07 +08:00
|
|
|
unsigned int pmem_sector_size(struct nd_namespace_common *ndns);
|
2020-10-14 07:50:29 +08:00
|
|
|
struct range;
|
2016-04-08 11:02:06 +08:00
|
|
|
void nvdimm_badblocks_populate(struct nd_region *nd_region,
|
2020-10-14 07:50:29 +08:00
|
|
|
struct badblocks *bb, const struct range *range);
|
2019-10-31 18:57:41 +08:00
|
|
|
int devm_namespace_enable(struct device *dev, struct nd_namespace_common *ndns,
|
|
|
|
|
resource_size_t size);
|
|
|
|
|
void devm_namespace_disable(struct device *dev,
|
|
|
|
|
struct nd_namespace_common *ndns);
|
2016-03-22 15:22:16 +08:00
|
|
|
#if IS_ENABLED(CONFIG_ND_CLAIM)
|
2019-09-05 23:45:59 +08:00
|
|
|
/* max struct page size independent of kernel config */
|
|
|
|
|
#define MAX_STRUCT_PAGE_SIZE 64
|
2017-12-29 15:54:05 +08:00
|
|
|
int nvdimm_setup_pfn(struct nd_pfn *nd_pfn, struct dev_pagemap *pgmap);
|
2016-03-22 15:22:16 +08:00
|
|
|
#else
|
2017-12-29 15:54:05 +08:00
|
|
|
static inline int nvdimm_setup_pfn(struct nd_pfn *nd_pfn,
|
|
|
|
|
struct dev_pagemap *pgmap)
|
2016-03-22 15:29:43 +08:00
|
|
|
{
|
2017-12-29 15:54:05 +08:00
|
|
|
return -ENXIO;
|
2016-03-22 15:29:43 +08:00
|
|
|
}
|
2016-03-22 15:22:16 +08:00
|
|
|
#endif
|
2015-06-25 16:21:02 +08:00
|
|
|
int nd_blk_region_init(struct nd_region *nd_region);
|
2016-06-08 08:00:04 +08:00
|
|
|
int nd_region_activate(struct nd_region *nd_region);
|
2016-03-22 15:22:16 +08:00
|
|
|
static inline bool is_bad_pmem(struct badblocks *bb, sector_t sector,
|
|
|
|
|
unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
if (bb->count) {
|
|
|
|
|
sector_t first_bad;
|
|
|
|
|
int num_bad;
|
|
|
|
|
|
|
|
|
|
return !!badblocks_check(bb, sector, len / 512, &first_bad,
|
|
|
|
|
&num_bad);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2015-06-25 16:21:02 +08:00
|
|
|
resource_size_t nd_namespace_blk_validate(struct nd_namespace_blk *nsblk);
|
2015-07-30 04:58:09 +08:00
|
|
|
const u8 *nd_dev_to_uuid(struct device *dev);
|
2015-08-25 07:20:23 +08:00
|
|
|
bool pmem_should_map_pages(struct device *dev);
|
2015-06-01 02:41:48 +08:00
|
|
|
#endif /* __ND_H__ */
|
