| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix punctuation and wording in a few places.
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Dan Williams <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>
|
|
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 <[email protected]>
Cc: Dave Jiang <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Link: https://lore.kernel.org/r/157462919825.1729495.5877405723948988416.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Jonathan Corbet <[email protected]>
|
|
The descriptions here are from Kernel driver's PoV.
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Acked-by: Dan Williams <[email protected]>
|
|
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 <[email protected]>
Acked-by: Dan Williams <[email protected]>
|
|
Remove the extra 'we '.
Signed-off-by: Shiyang Ruan <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
|
|
Add theory of operation for the security support that's going into
libnvdimm.
Signed-off-by: Dave Jiang <[email protected]>
Reviewed-by: Jing Lin <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
|
|
A bunch of changes that I hope will help in understanding it
better for first-time readers.
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
|
|
Maintainer information and documentation for drivers/nvdimm
Cc: Andy Lutomirski <[email protected]>
Cc: Boaz Harrosh <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Neil Brown <[email protected]>
Cc: Greg KH <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
|
|
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 <[email protected]>
Cc: Boaz Harrosh <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Neil Brown <[email protected]>
Cc: Jeff Moyer <[email protected]>
Cc: Dave Chinner <[email protected]>
Cc: Greg KH <[email protected]>
[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 <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
|