Re: Picking 0th namespace if it is idle

aneesh.ku...@linux.ibm.com (Aneesh Kumar K.V) writes: > Hi Dan, > > With the patch series to mark the namespace disabled if we have mismatch > in pfn superblock, we can endup with namespace0 marked idle/disabled. > > I am wondering why do do the below in ndctl. > > > static struct ndctl_namespace

Re: [PATCH 04/18] dax: Introduce IOMAP_DAX_COW to CoW edges during writes

On Thu 30-05-19 08:14:45, Dave Chinner wrote: > On Wed, May 29, 2019 at 03:46:29PM +0200, Jan Kara wrote: > > On Wed 29-05-19 14:46:58, Dave Chinner wrote: > > > iomap_apply() > > > > > > ->iomap_begin() > > > map old data extent that we copy from > > > > > > allocate new d

Re: [RFC PATCH V2 1/3] mm/nvdimm: Add PFN_MIN_VERSION support

Hi Dan, Are you ok with this patch series? If yes I can send a non-RFC version for this series. Since we are now marking all previously created pfn_sb on ppc64 as not supported, (pfn_sb->page_size = SZ_4K) I would like to get this merged early. -aneesh "Aneesh Kumar K.V" writes: > This allow

Re: [PATCH 04/18] dax: Introduce IOMAP_DAX_COW to CoW edges during writes

On Thu, May 30, 2019 at 01:16:05PM +0200, Jan Kara wrote: > On Thu 30-05-19 08:14:45, Dave Chinner wrote: > > On Wed, May 29, 2019 at 03:46:29PM +0200, Jan Kara wrote: > > > On Wed 29-05-19 14:46:58, Dave Chinner wrote: > > > > iomap_apply() > > > > > > > > ->iomap_begin() > > > >

[PATCH v2 4/8] x86, efi: Reserve UEFI 2.8 Specific Purpose Memory for dax

UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the interpretation of the EFI Memory Types as "reserved for a special purpose". The proposed Linux behavior for specific purpose memory is that it is reserved for direct-access (device-dax) by default and not available for any kernel usage

[PATCH v2 0/8] EFI Specific Purpose Memory Support

Changes since the initial RFC [1] * Split the generic detection of the attribute from any policy / mechanism that leverages the EFI_MEMORY_SP designation (Ard). * Various cleanups to the lib/memregion implementation (Willy) * Rebase on v5.2-rc2 * Several fixes resulting from testing with efi_f

[PATCH v2 6/8] device-dax: Add a driver for "hmem" devices

Platform firmware like EFI/ACPI may publish "hmem" platform devices. Such a device is a performance differentiated memory range likely reserved for an application specific use case. The driver gives access to 100% of the capacity via a device-dax mmap instance by default. However, if over-subscrip

[PATCH v2 1/8] acpi: Drop drivers/acpi/hmat/ directory

As a single source file object there is no need for the hmat enabling to have its own directory. Cc: Len Brown Cc: Keith Busch Cc: "Rafael J. Wysocki" Signed-off-by: Dan Williams --- drivers/acpi/Kconfig | 12 +++- drivers/acpi/Makefile |2 +- drivers/acpi/hmat.c

[PATCH v2 5/8] lib/memregion: Uplevel the pmem "region" ida to a global allocator

In preparation for handling platform differentiated memory types beyond persistent memory, uplevel the "region" identifier to a global number space. This enables a device-dax instance to be registered to any memory type with guaranteed unique names. Cc: Keith Busch Cc: Matthew Wilcox Signed-off-

[PATCH v2 2/8] acpi/hmat: Skip publishing target info for nodes with no online memory

There are multiple scenarios where the HMAT may contain information about proximity domains that are not currently online. Rather than fail to report any HMAT data just elide those offline domains. If and when those domains are later onlined they can be added to the HMEM reporting at that point.

[PATCH v2 3/8] efi: Enumerate EFI_MEMORY_SP

UEFI 2.8 defines an EFI_MEMORY_SP attribute bit to augment the interpretation of the EFI Memory Types as "reserved for a specific purpose". The intent of this bit is to allow the OS to identify precious or scarce memory resources and optionally manage it separately from EfiConventionalMemory. As de

[PATCH v2 7/8] acpi/hmat: Register HMAT at device_initcall level

In preparation for registering device-dax instances for accessing EFI specific-purpose memory, arrange for the HMAT registration to occur later in the init process. Critically HMAT initialization needs to occur after e820__reserve_resources_late() which is the point at which the iomem resource tree

[PATCH v2 8/8] acpi/hmat: Register "specific purpose" memory as an "hmem" device

Memory that has been tagged EFI_MEMORY_SP, and has performance properties described by the ACPI HMAT is expected to have an application specific consumer. Those consumers may want 100% of the memory capacity to be reserved from any usage by the kernel. By default, with this enabling, a platform de

Re: [PATCH v2 0/6] mm/devm_memremap_pages: Fix page release race

On Mon, May 13, 2019 at 12:22 PM Logan Gunthorpe wrote: > > > > On 2019-05-08 11:05 a.m., Logan Gunthorpe wrote: > > > > > > On 2019-05-07 5:55 p.m., Dan Williams wrote: > >> Changes since v1 [1]: > >> - Fix a NULL-pointer deref crash in pci_p2pdma_release() (Logan) > >> > >> - Refresh the p2pdma

Re: [Qemu-devel] [PATCH v4 00/11] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

On Tue, May 7, 2019 at 11:32 PM Tao Xu wrote: > > This series of patches will build Heterogeneous Memory Attribute Table (HMAT) > according to the command line. The ACPI HMAT describes the memory attributes, > such as memory side cache attributes and bandwidth and latency details, > related to the