path: root/Documentation/nvdimm
AgeCommit message (Collapse)Author
2020-05-25nvdimm: fixes to maintainter-entry-profileRandy Dunlap
Fix punctuation and wording in a few places. Signed-off-by: Randy Dunlap <> Cc: Dan Williams <> Link: Signed-off-by: Jonathan Corbet <>
2020-01-24docs: nvdimm: use ReST notation for subsectionLukas Bulwahn
The ACPI Device Specific Methods (_DSM) paragraph is intended to be a subsection of the Submit Checklist Addendum section. Dan Williams however used Markdown notation for this subsection, which does not parse as intended in a ReST documentation. Change the markup to ReST notation, as described in the Specific guidelines for the kernel documentation section in Documentation/doc-guide/sphinx.rst. Fixes: 47843401e3a0 ("libnvdimm, MAINTAINERS: Maintainer Entry Profile") Signed-off-by: Lukas Bulwahn <> Link: Signed-off-by: Jonathan Corbet <>
2019-11-25libnvdimm, MAINTAINERS: Maintainer Entry ProfileDan Williams
Document the basic policies of the libnvdimm subsystem and provide a first example of a Maintainer Entry Profile for others to duplicate and edit. Cc: Vishal Verma <> Cc: Dave Jiang <> Signed-off-by: Dan Williams <> Link: Signed-off-by: Jonathan Corbet <>
2019-07-15docs: nvdimm: add it to the driver-api bookMauro Carvalho Chehab
The descriptions here are from Kernel driver's PoV. Signed-off-by: Mauro Carvalho Chehab <> Acked-by: Dan Williams <>
2019-07-15docs: nvdimm: convert to ReSTMauro Carvalho Chehab
Rename the nvdimm documentation files to ReST, add an index for them and adjust in order to produce a nice html output via the Sphinx build system. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <> Acked-by: Dan Williams <>
2019-06-07Documentation: nvdimm: Fix typoShiyang Ruan
Remove the extra 'we '. Signed-off-by: Shiyang Ruan <> Signed-off-by: Jonathan Corbet <>
2018-12-21libnvdimm/security: Add documentation for nvdimm security supportDave Jiang
Add theory of operation for the security support that's going into libnvdimm. Signed-off-by: Dave Jiang <> Reviewed-by: Jing Lin <> Signed-off-by: Dan Williams <>
2016-06-17libnvdimm, btt: update the usage section in DocumentationVishal Verma
Section 5 about BTT's in kernel usage was quite obsolete, replace it with a simple 'Usage' section that describes how to set up a BTT namespace using the 'ndctl' utility. Signed-off-by: Vishal Verma <> Signed-off-by: Dan Williams <>
2015-11-12libnvdimm: documentation clarificationsKonrad Rzeszutek Wilk
A bunch of changes that I hope will help in understanding it better for first-time readers. Signed-off-by: Konrad Rzeszutek Wilk <> Signed-off-by: Dan Williams <>
2015-06-26libnvdimm: Non-Volatile DevicesDan Williams
Maintainer information and documentation for drivers/nvdimm Cc: Andy Lutomirski <> Cc: Boaz Harrosh <> Cc: H. Peter Anvin <> Cc: Jens Axboe <> Cc: Ingo Molnar <> Cc: Christoph Hellwig <> Cc: Neil Brown <> Cc: Greg KH <> Signed-off-by: Dan Williams <>
2015-06-26nd_btt: atomic sector updatesVishal Verma
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 <> Cc: Boaz Harrosh <> Cc: H. Peter Anvin <> Cc: Jens Axboe <> Cc: Ingo Molnar <> Cc: Christoph Hellwig <> Cc: Neil Brown <> Cc: Jeff Moyer <> Cc: Dave Chinner <> Cc: Greg KH <> [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 <> Signed-off-by: Dan Williams <>