For example, "ndctl list -m dax" list all the namespaces that are
hosting a device-dax region.
Signed-off-by: Dan Williams
---
ndctl/builtin-list.c | 33 -
ndctl/libndctl.h.in |1 +
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/ndctl/builti
---
ndctl/Makefile.am |2 +-
test/Makefile.am |4 ++--
util/json.c |0
util/json.h |0
4 files changed, 3 insertions(+), 3 deletions(-)
rename ndctl/util/json.c => util/json.c (100%)
rename ndctl/util/json.h => util/json.h (100%)
diff --git a/ndctl/Makefile.am b/
Allow the region to be selected by type. For example, disable all pmem:
ndctl disable-region -t pmem all
One case this is useful for is scripting the bring-up of individual
namespaces rather than the default of all at once and in parallel. For
example:
* blacklist the nd_pmem module
* di
Single out the mapping for the requested dimm device when specified.
Signed-off-by: Dan Williams
---
ndctl/builtin-list.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/ndctl/builtin-list.c b/ndctl/builtin-list.c
index ed4edf6f0249..e8d007003b62 100644
--- a/ndctl/builtin-list.c
+++ b
Prepare the generic command infrastructure for reuse with daxctl.
Signed-off-by: Dan Williams
---
Makefile.am |2
ndctl/Makefile.am |1
ndctl/builtin-bat.c |2
ndctl/builtin-create-nfit.c |2
ndctl/builtin-dimm.c
Only include dax region and sub-device info when requested by this new
option to ndctl list. If '--device-dax' is the only option then the
listing will only include namespaces in device-dax mode.
Signed-off-by: Dan Williams
---
ndctl/builtin-list.c |7 ++-
ndctl/builtin-xact
Similar to "ndctl list", provide a utility for generically dumping all
the device-dax regions and device instances in a system.
Signed-off-by: Dan Williams
---
Makefile.am|2 -
builtin.h |0
configure.ac |1
daxctl/Makefile.am | 13 ++
d
* The 'ndctl list' command awkwardly prints out all the corresponding
device-dax information when a namespace is in 'dax' mode. Conversely if
someone is only interested in listing device-dax information they need to
contend with libnvdimm data.
Introduce a separate daxctl utility with its
The ->bd_queue member of struct block_device was added in commit
87192a2a49c4 ("vfs: cache request_queue in struct block_device") in
v3.3. However, blk_get_backing_dev_info() has been using
bdev_get_queue() and grabbing the request_queue through the gendisk
since before the git era.
At final __blk
v1 of these changes [1] was a one line change to bdev_get_queue() to
prevent a shutdown crash when del_gendisk() races the final
__blkdev_put().
While it is known at del_gendisk() time that the queue is still alive,
Jan Kara points to other paths [2] that are racing __blkdev_put() where
the assump
By definition the lifetime of a struct block_device is equal to the
lifetime of its corresponding inode since they both live in struct
bdev_inode. Up until the inode is destroyed it may be the target of
delayed write-back requests. Issuing write-back to a block_device
requires a lookup of the bdev
On 06/01/17 11:26 AM, Jason Gunthorpe wrote:
> Make a generic API for all of this and you'd have my vote..
>
> IMHO, you must support basic pinning semantics - that is necessary to
> support generic short lived DMA (eg filesystem, etc). That hardware
> can clearly do that if it can support ODP.
On Thu, Jan 5, 2017 at 6:44 PM, Baoquan He wrote:
> Add Kees to let him have a look at this too.
>
> On 01/05/17 at 05:21pm, Baoquan He wrote:
>> On 01/04/17 at 11:29am, Dave Jiang wrote:
>> > CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address.
>> > However it does not take into a
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Sent: Friday, January 06, 2017 1:26 PM
> To: Jerome Glisse
> Cc: Sagalovitch, Serguei; Jerome Glisse; Deucher, Alexander; 'linux-
> ker...@vger.kernel.org'; 'linux-r...@vger.kernel.org'; 'linux-
> nvd...
Clearing out the poison in the metadata block of the namespace before
we use it. Range from start + 8k to pfn_sb->dataoff.
Signed-off-by: Dave Jiang
---
drivers/nvdimm/pfn_devs.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/nvdimm/pfn_devs.c b/drivers/
On Fri, Jan 06, 2017 at 12:37:22PM -0500, Jerome Glisse wrote:
> On Fri, Jan 06, 2017 at 11:56:30AM -0500, Serguei Sagalovitch wrote:
> > On 2017-01-05 08:58 PM, Jerome Glisse wrote:
> > > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote:
> > > > On Thu, Jan 05, 2017 at 06:23:52PM -0
On Thu, Jan 05, 2017 at 05:27:34PM -0800, Andrew Morton wrote:
> On Tue, 3 Jan 2017 17:13:49 -0700 Ross Zwisler
> wrote:
>
> > On Thu, Dec 22, 2016 at 02:18:52PM -0700, Ross Zwisler wrote:
> > > Currently dax_mapping_entry_mkclean() fails to clean and write protect the
> > > pmd_t of a DAX PMD e
On Fri, Jan 06, 2017 at 11:56:30AM -0500, Serguei Sagalovitch wrote:
> On 2017-01-05 08:58 PM, Jerome Glisse wrote:
> > On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote:
> > > On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote:
> > >
> > > > > I still don't understand wha
On 2017-01-05 08:58 PM, Jerome Glisse wrote:
On Thu, Jan 05, 2017 at 05:30:34PM -0700, Jason Gunthorpe wrote:
On Thu, Jan 05, 2017 at 06:23:52PM -0500, Jerome Glisse wrote:
I still don't understand what you driving at - you've said in both
cases a user VMA exists.
In the former case no, there
Hello, I've been watching this thread not as a kernel developer, but
as an user interested in doing peer-to-peer access between network
card and GPU. I believe that merging raw direct access with vma
overcomplicates things for our use case. We'll have a very large
camera streaming data at high thr
20 matches
Mail list logo