[ndctl PATCH] ndctl: allow bus device names as a filter option

For example, allow: ndctl list -b ndbus0 ...in addition to the existing provider based method: ndctl list -b ACPI.NFIT ...or the id based method: ndctl list -b 0 Cc: Vishal Verma Reported-by: Dave Jiang Signed-off-by: Dan Williams

Persistent Memory type vs Reserved Memory type

Hi:    I am trying to debug an issue related to  my private built kernel's (4.11 from upstream with ACPI/NFIT/NVDIMM enabled) interaction with a persistent memory device's type. We have a way to emulate a software based NVDIMM device into a guest, which is running my private built kernel. When

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Wed, Jul 19, 2017 at 11:51:12AM -0600, Ross Zwisler wrote: > On Wed, Jul 19, 2017 at 04:16:59PM +0200, Jan Kara wrote: > > On Wed 28-06-17 16:01:48, Ross Zwisler wrote: > > > To be able to use the common 4k zero page in DAX we need to have our PTE > > > fault path look more like our PMD fault

Re: [ndctl PATCH 4/6] ndctl, list: emit device-dax 'chardev' by default

On 07/19/2017 02:33 PM, Dan Williams wrote: > Commit 10663a60d723 "ndctl, list: add '--device-dax' option" tried to > cleanup the default namespace output by putting the device-dax details > behind an extra option. This was done in anticipation of device-dax > sub-division support, but the kernel

[ndctl PATCH 3/6] daxctl: fix support for multiple instances per-region id

If libnvdimm registers namespace0.0 and namespace0.1 as device-dax-regions there will be 2 entries in /sys/class/dax, dax0.0 and dax0.1. However, libdaxctl does not account for the fact that these two devices are hosted by 2 separate parent devices. Fix this assumption and create separate regions

[ndctl PATCH 6/6] test: add multi-dax test

Add a simple sanity check for multiple dax instances per libnvdimm-region support. This is known to fail with a sysfs duplicate filename warning on kernels prior to 4.13-final. Signed-off-by: Dan Williams --- test/Makefile.am |1 + test/multi-dax.sh | 61

[ndctl PATCH 4/6] ndctl, list: emit device-dax 'chardev' by default

Commit 10663a60d723 "ndctl, list: add '--device-dax' option" tried to cleanup the default namespace output by putting the device-dax details behind an extra option. This was done in anticipation of device-dax sub-division support, but the kernel has since added support for multiple-pmem namespaces

[ndctl PATCH 5/6] daxctl, list: clarify output when multiple regions share an id

The region id is meant to uniquely identify a host memory range, but in the case of the libnvdimm namespace the host memory range may be sub-divided into multiple namespaces leading to ambiguous output like the following # daxctl list -R [ { "id":1,

[ndctl PATCH 1/6] ndctl, daxctl: propagate loglevel to internal libdaxctl instance

If someone turns on libndctl debug they automatically get libdaxctl debug output from the internal library instance. Signed-off-by: Dan Williams --- ndctl/lib/libndctl.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/ndctl/lib/libndctl.c

[ndctl PATCH 2/6] daxctl: stop carrying 'dax_region' in the daxctl_region region_path

Clean up region_path to carry the region device path directly. This aligns libdaxctl with libndctl internal path names, and is a preparation for carrying absolute path names that are needed for multi-device-dax per region support. Signed-off-by: Dan Williams ---

[ndctl PATCH 0/6] multi-device-dax support and other fixes

A test report highlighted the fact that the unit tests never verified that multiple-namespaces in a region could be in device-dax mode. This was fixed in the kernel [1], but there is some fallout to handle in ndctl and daxctl: 1/ teach libdaxctl that there may be multiple dax-region instances

[PATCH] device-dax: fix sysfs duplicate warnings

Fix warnings of the form... WARNING: CPU: 10 PID: 4983 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/class/dax/dax12.0' Call Trace: dump_stack+0x63/0x86 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5a/0x80 ?

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Wed, Jul 19, 2017 at 04:16:59PM +0200, Jan Kara wrote: > On Wed 28-06-17 16:01:48, Ross Zwisler wrote: > > To be able to use the common 4k zero page in DAX we need to have our PTE > > fault path look more like our PMD fault path where a PTE entry can be > > marked as dirty and writeable as it

Re: [PATCH v3 3/5] dax: use common 4k zero page for dax mmap reads

On Wed, Jul 19, 2017 at 05:33:14PM +0200, Jan Kara wrote: > On Wed 28-06-17 16:01:50, Ross Zwisler wrote: > > Another major change is that we remove dax_pfn_mkwrite() from our fault > > flow, and instead rely on the page fault itself to make the PTE dirty and > > writeable. The following

Re: [PATCH v3 3/5] dax: use common 4k zero page for dax mmap reads

On Wed 28-06-17 16:01:50, Ross Zwisler wrote: > Another major change is that we remove dax_pfn_mkwrite() from our fault > flow, and instead rely on the page fault itself to make the PTE dirty and > writeable. The following description from the patch adding the > vm_insert_mixed_mkwrite() call

Re: [RFC v2 0/5] surface heterogeneous memory performance information

On 07/19/2017 02:48 AM, Bob Liu wrote: >> Option 2: Provide the user with HMAT performance data directly in >> sysfs, allowing applications to directly access it without the need >> for the library and daemon. >> > Is it possible to do the memory allocation automatically by the > kernel and

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

On Wed 28-06-17 16:01:48, Ross Zwisler wrote: > To be able to use the common 4k zero page in DAX we need to have our PTE > fault path look more like our PMD fault path where a PTE entry can be > marked as dirty and writeable as it is first inserted, rather than waiting > for a follow-up

Re: [RFC v2 0/5] surface heterogeneous memory performance information

On 2017/7/7 5:52, Ross Zwisler wrote: > Quick Summary > > Platforms in the very near future will have multiple types of memory > attached to a single CPU. These disparate memory ranges will have some > characteristics in common, such as CPU cache coherence, but they can have > wide

Returned mail: see transcript for details

This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely