linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Barrat <fbarrat@linux.ibm.com>
To: "Alastair D'Silva" <alastair@au1.ibm.com>, alastair@d-silva.org
Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
	"Oliver O'Halloran" <oohall@gmail.com>,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Paul Mackerras" <paulus@samba.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Andrew Donnellan" <ajd@linux.ibm.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Vishal Verma" <vishal.l.verma@intel.com>,
	"Dave Jiang" <dave.jiang@intel.com>,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Mauro Carvalho Chehab" <mchehab+samsung@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Rob Herring" <robh@kernel.org>,
	"Anton Blanchard" <anton@ozlabs.org>,
	"Krzysztof Kozlowski" <krzk@kernel.org>,
	"Mahesh Salgaonkar" <mahesh@linux.vnet.ibm.com>,
	"Madhavan Srinivasan" <maddy@linux.vnet.ibm.com>,
	"Cédric Le Goater" <clg@kaod.org>,
	"Anju T Sudhakar" <anju@linux.vnet.ibm.com>,
	"Hari Bathini" <hbathini@linux.ibm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Greg Kurz" <groug@kaod.org>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Masahiro Yamada" <yamada.masahiro@socionext.com>,
	"Alexey Kardashevskiy" <aik@ozlabs.ru>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-nvdimm@lists.01.org, linux-mm@kvack.org
Subject: Re: [PATCH v3 19/27] powerpc/powernv/pmem: Add an IOCTL to report controller statistics
Date: Wed, 4 Mar 2020 10:25:15 +0100	[thread overview]
Message-ID: <6ee036c7-f4ea-4e42-faad-66a1921553ce@linux.ibm.com> (raw)
In-Reply-To: <20200221032720.33893-20-alastair@au1.ibm.com>



Le 21/02/2020 à 04:27, Alastair D'Silva a écrit :
> From: Alastair D'Silva <alastair@d-silva.org>
> 
> The controller can report a number of statistics that are useful
> in evaluating the performance and reliability of the card.
> 
> This patch exposes this information via an IOCTL.
> 
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> ---
>   arch/powerpc/platforms/powernv/pmem/ocxl.c | 185 +++++++++++++++++++++
>   include/uapi/nvdimm/ocxl-pmem.h            |  17 ++
>   2 files changed, 202 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/powernv/pmem/ocxl.c b/arch/powerpc/platforms/powernv/pmem/ocxl.c
> index 2cabafe1fc58..009d4fd29e7d 100644
> --- a/arch/powerpc/platforms/powernv/pmem/ocxl.c
> +++ b/arch/powerpc/platforms/powernv/pmem/ocxl.c
> @@ -758,6 +758,186 @@ static int ioctl_controller_dump_complete(struct ocxlpmem *ocxlpmem)
>   				    GLOBAL_MMIO_HCI_CONTROLLER_DUMP_COLLECTED);
>   }
>   
> +/**
> + * controller_stats_header_parse() - Parse the first 64 bits of the controller stats admin command response
> + * @ocxlpmem: the device metadata
> + * @length: out, returns the number of bytes in the response (excluding the 64 bit header)
> + */
> +static int controller_stats_header_parse(struct ocxlpmem *ocxlpmem,
> +	u32 *length)
> +{
> +	int rc;
> +	u64 val;
> +


unexpected empty line


> +	u16 data_identifier;
> +	u32 data_length;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset,
> +				     OCXL_LITTLE_ENDIAN, &val);
> +	if (rc)
> +		return rc;
> +
> +	data_identifier = val >> 48;
> +	data_length = val & 0xFFFFFFFF;
> +
> +	if (data_identifier != 0x4353) { // 'CS'
> +		dev_err(&ocxlpmem->dev,
> +			"Bad data identifier for controller stats, expected 'CS', got '%-.*s'\n",
> +			2, (char *)&data_identifier);



Wow, I'm clueless what that string format looks like :-)
2 arguments? Did you check the kernel string formatter does what you want?
You may consider unifying the format though, the error log patch uses a 
simpler (better?) format for a similar message.



> +		return -EINVAL;
> +	}
> +
> +	*length = data_length;
> +	return 0;
> +}
> +
> +static int ioctl_controller_stats(struct ocxlpmem *ocxlpmem,
> +				  struct ioctl_ocxl_pmem_controller_stats __user *uarg)
> +{
> +	struct ioctl_ocxl_pmem_controller_stats args;
> +	u32 length;
> +	int rc;
> +	u64 val;
> +
> +	memset(&args, '\0', sizeof(args));
> +
> +	mutex_lock(&ocxlpmem->admin_command.lock);
> +
> +	rc = admin_command_request(ocxlpmem, ADMIN_COMMAND_CONTROLLER_STATS);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_write64(ocxlpmem->ocxl_afu,
> +				      ocxlpmem->admin_command.request_offset + 0x08,
> +				      OCXL_LITTLE_ENDIAN, 0);
> +	if (rc)
> +		goto out;
> +
> +	rc = admin_command_execute(ocxlpmem);
> +	if (rc)
> +		goto out;
> +
> +
> +	rc = admin_command_complete_timeout(ocxlpmem,
> +					    ADMIN_COMMAND_CONTROLLER_STATS);
> +	if (rc < 0) {
> +		dev_warn(&ocxlpmem->dev, "Controller stats timed out\n");
> +		goto out;
> +	}
> +
> +	rc = admin_response(ocxlpmem);
> +	if (rc < 0)
> +		goto out;
> +	if (rc != STATUS_SUCCESS) {
> +		warn_status(ocxlpmem,
> +			    "Unexpected status from controller stats", rc);
> +		goto out;
> +	}


All those ioctls commands follow the same pattern:
1. admin_command_request()
2. optionnaly, set some mmio registers specific to the command
3. admin_command_execute()
4. admin_command_complete_timeout()
5. admin_response()

By swapping 1 and 2, we could then factorize steps 1, 3, 4 and 5 in a 
function and simplify/shorten the code each time a command is called.

Regarding step 2 (and that's true for all similar patches), a comment 
about what the mmio tuning does would help and avoid looking up the 
spec. Looking up the spec during the review is expected, but it will 
ease reading the code 6 months from now.



> +
> +	rc = controller_stats_header_parse(ocxlpmem, &length);
> +	if (rc)
> +		goto out;
> +
> +	if (length != 0x140)
> +		warn_status(ocxlpmem,
> +			    "Unexpected length for controller stats data, expected 0x140, got 0x%x",
> +			    length);
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x08,
> +				     OCXL_LITTLE_ENDIAN, &val);
> +	if (rc)
> +		goto out;
> +
> +	args.reset_count = val >> 32;
> +	args.reset_uptime = val & 0xFFFFFFFF;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x10,
> +				     OCXL_LITTLE_ENDIAN, &val);
> +	if (rc)
> +		goto out;
> +
> +	args.power_on_uptime = val >> 32;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x08,
 > +				     OCXL_LITTLE_ENDIAN, &args.host_load_count);


Those offsets are hard to understand, even with the spec next to me. And 
it seems that we could harden things a bit:
each block as a "statistics parameter ID" and the length of the data for 
that block. We should check that and make sure we're reading what we expect.
For example, from the spec I'm looking (110d), I would expect the host 
load count to be at offset 0x10. It's entirely possible I'm misreading 
it though.



> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x10,
> +				     OCXL_LITTLE_ENDIAN, &args.host_store_count);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x18,
> +				     OCXL_LITTLE_ENDIAN, &args.media_read_count);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x20,
> +				     OCXL_LITTLE_ENDIAN, &args.media_write_count);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x28,
> +				     OCXL_LITTLE_ENDIAN, &args.cache_hit_count);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x30,
> +				     OCXL_LITTLE_ENDIAN, &args.cache_miss_count);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x38,
> +				     OCXL_LITTLE_ENDIAN, &args.media_read_latency);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x40,
> +				     OCXL_LITTLE_ENDIAN, &args.media_write_latency);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x48,
> +				     OCXL_LITTLE_ENDIAN, &args.cache_read_latency);
> +	if (rc)
> +		goto out;
> +
> +	rc = ocxl_global_mmio_read64(ocxlpmem->ocxl_afu,
> +				     ocxlpmem->admin_command.data_offset + 0x08 + 0x40 + 0x50,
> +				     OCXL_LITTLE_ENDIAN, &args.cache_write_latency);
> +	if (rc)
> +		goto out;
> +
> +	if (copy_to_user(uarg, &args, sizeof(args))) {
> +		rc = -EFAULT;
> +		goto out;
> +	}
> +
> +	rc = admin_response_handled(ocxlpmem);
> +	if (rc)
> +		goto out;
> +
> +	rc = 0;
> +	goto out;


That may be more of a personal habit, but that final goto disrupts the 
"good case" flow. And I think it's pretty unusual within the kernel.


> +
> +out:
> +	mutex_unlock(&ocxlpmem->admin_command.lock);
> +	return rc;
> +}
> +
>   static long file_ioctl(struct file *file, unsigned int cmd, unsigned long args)
>   {
>   	struct ocxlpmem *ocxlpmem = file->private_data;
> @@ -781,6 +961,11 @@ static long file_ioctl(struct file *file, unsigned int cmd, unsigned long args)
>   	case IOCTL_OCXL_PMEM_CONTROLLER_DUMP_COMPLETE:
>   		rc = ioctl_controller_dump_complete(ocxlpmem);
>   		break;
> +
> +	case IOCTL_OCXL_PMEM_CONTROLLER_STATS:
> +		rc = ioctl_controller_stats(ocxlpmem,
> +					    (struct ioctl_ocxl_pmem_controller_stats __user *)args);
> +		break;
>   	}
>   
>   	return rc;
> diff --git a/include/uapi/nvdimm/ocxl-pmem.h b/include/uapi/nvdimm/ocxl-pmem.h
> index d4d8512d03f7..add223aa2fdb 100644
> --- a/include/uapi/nvdimm/ocxl-pmem.h
> +++ b/include/uapi/nvdimm/ocxl-pmem.h
> @@ -50,6 +50,22 @@ struct ioctl_ocxl_pmem_controller_dump_data {
>   	__u64 reserved[8];
>   };
>   
> +struct ioctl_ocxl_pmem_controller_stats {
> +	__u32 reset_count;
> +	__u32 reset_uptime; /* seconds */
> +	__u32 power_on_uptime; /* seconds */


Same as before, we're going to have some padding here.

   Fred


> +	__u64 host_load_count;
> +	__u64 host_store_count;
> +	__u64 media_read_count;
> +	__u64 media_write_count;
> +	__u64 cache_hit_count;
> +	__u64 cache_miss_count;
> +	__u64 media_read_latency; /* nanoseconds */
> +	__u64 media_write_latency; /* nanoseconds */
> +	__u64 cache_read_latency; /* nanoseconds */
> +	__u64 cache_write_latency; /* nanoseconds */
> +};
> +
>   /* ioctl numbers */
>   #define OCXL_PMEM_MAGIC 0x5C
>   /* SCM devices */
> @@ -57,5 +73,6 @@ struct ioctl_ocxl_pmem_controller_dump_data {
>   #define IOCTL_OCXL_PMEM_CONTROLLER_DUMP			_IO(OCXL_PMEM_MAGIC, 0x02)
>   #define IOCTL_OCXL_PMEM_CONTROLLER_DUMP_DATA		_IOWR(OCXL_PMEM_MAGIC, 0x03, struct ioctl_ocxl_pmem_controller_dump_data)
>   #define IOCTL_OCXL_PMEM_CONTROLLER_DUMP_COMPLETE	_IO(OCXL_PMEM_MAGIC, 0x04)
> +#define IOCTL_OCXL_PMEM_CONTROLLER_STATS		_IO(OCXL_PMEM_MAGIC, 0x05)
>   
>   #endif /* _UAPI_OCXL_SCM_H */
> 



  reply	other threads:[~2020-03-04  9:25 UTC|newest]

Thread overview: 130+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21  3:26 [PATCH v3 00/27] Add support for OpenCAPI Persistent Memory devices Alastair D'Silva
2020-02-21  3:26 ` [PATCH v3 01/27] powerpc: Add OPAL calls for LPC memory alloc/release Alastair D'Silva
2020-02-24  5:49   ` Andrew Donnellan
2020-02-24  5:50     ` Alastair D'Silva
2020-02-21  3:26 ` [PATCH v3 02/27] mm/memory_hotplug: Allow check_hotplug_memory_addressable to be called from drivers Alastair D'Silva
2020-02-21  7:03   ` Andrew Donnellan
2020-02-21  3:26 ` [PATCH v3 03/27] powerpc: Map & release OpenCAPI LPC memory Alastair D'Silva
2020-02-24  2:51   ` Andrew Donnellan
2020-02-24  5:49     ` Andrew Donnellan
2020-02-25 10:02   ` Frederic Barrat
2020-02-26  0:19     ` Alastair D'Silva
2020-03-03  6:10   ` Andrew Donnellan
2020-03-04  5:33     ` Alastair D'Silva
2020-02-21  3:26 ` [PATCH v3 04/27] ocxl: Remove unnecessary externs Alastair D'Silva
2020-02-21  6:06   ` Andrew Donnellan
2020-02-25 13:23   ` Frederic Barrat
2020-02-26  8:14   ` Baoquan He
2020-02-26  8:26     ` Alastair D'Silva
2020-02-26  9:01       ` Greg Kurz
2020-02-26 14:15         ` 'Baoquan He'
2020-02-26 14:20           ` Greg Kurz
2020-02-26 14:54             ` 'Baoquan He'
2020-02-21  3:26 ` [PATCH v3 05/27] ocxl: Address kernel doc errors & warnings Alastair D'Silva
2020-02-24  2:11   ` Andrew Donnellan
2020-02-21  3:26 ` [PATCH v3 06/27] ocxl: Tally up the LPC memory on a link & allow it to be mapped Alastair D'Silva
2020-02-24  5:25   ` Andrew Donnellan
2020-02-24  5:36     ` Alastair D'Silva
2020-02-25 16:30   ` Frederic Barrat
2020-02-26  0:29     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 07/27] ocxl: Add functions to map/unmap LPC memory Alastair D'Silva
2020-02-24  6:02   ` Andrew Donnellan
2020-02-24  6:08     ` Alastair D'Silva
2020-02-25 17:01   ` Frederic Barrat
2020-02-21  3:27 ` [PATCH v3 08/27] ocxl: Emit a log message showing how much LPC memory was detected Alastair D'Silva
2020-02-24  6:06   ` Andrew Donnellan
2020-02-24  6:10     ` Alastair D'Silva
2020-02-24  6:13       ` Andrew Donnellan
2020-02-25 17:03   ` Frederic Barrat
2020-02-21  3:27 ` [PATCH v3 09/27] ocxl: Save the device serial number in ocxl_fn Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 10/27] powerpc: Add driver for OpenCAPI Persistent Memory Alastair D'Silva
2020-02-26  5:07   ` Andrew Donnellan
2020-02-26  5:49     ` Alastair D'Silva
2020-02-27 20:44   ` Frederic Barrat
2020-02-28  0:54     ` Alastair D'Silva
2020-02-28 18:32   ` Frederic Barrat
2020-02-21  3:27 ` [PATCH v3 11/27] powerpc: Enable the OpenCAPI Persistent Memory driver for powernv_defconfig Alastair D'Silva
2020-02-25  3:01   ` Andrew Donnellan
2020-02-21  3:27 ` [PATCH v3 12/27] powerpc/powernv/pmem: Add register addresses & status values to the header Alastair D'Silva
2020-02-27  5:08   ` Andrew Donnellan
2020-02-27  5:16     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 13/27] powerpc/powernv/pmem: Read the capability registers & wait for device ready Alastair D'Silva
2020-02-27  3:54   ` Andrew Donnellan
2020-02-27  3:58     ` Alastair D'Silva
2020-03-02 17:51   ` Frederic Barrat
2020-03-04  4:15     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 14/27] powerpc/powernv/pmem: Add support for Admin commands Alastair D'Silva
2020-02-27  8:22   ` Andrew Donnellan
2020-02-27  8:27     ` Andrew Donnellan
2020-02-27 23:54       ` Alastair D'Silva
2020-02-27 23:51     ` Alastair D'Silva
2020-02-27 17:01   ` Dan Williams
2020-02-27 23:57     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 15/27] powerpc/powernv/pmem: Add support for near storage commands Alastair D'Silva
2020-02-27  8:30   ` Andrew Donnellan
2020-02-27 23:56     ` Alastair D'Silva
2020-02-27 17:02   ` Dan Williams
2020-03-02 17:58   ` Frederic Barrat
2020-03-02 18:42     ` Dan Williams
2020-03-04  4:42       ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 16/27] powerpc/powernv/pmem: Register a character device for userspace to interact with Alastair D'Silva
2020-03-02  5:34   ` Andrew Donnellan
2020-03-02  6:05     ` Alastair D'Silva
2020-03-03  9:28   ` Frederic Barrat
2020-03-05  3:38     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 17/27] powerpc/powernv/pmem: Implement the Read Error Log command Alastair D'Silva
2020-03-03 10:36   ` Frederic Barrat
2020-03-05  4:31     ` Alastair D'Silva
2020-03-05  9:33       ` Frederic Barrat
2020-03-04  5:58   ` Andrew Donnellan
2020-02-21  3:27 ` [PATCH v3 18/27] powerpc/powernv/pmem: Add controller dump IOCTLs Alastair D'Silva
2020-03-03 18:04   ` Frederic Barrat
2020-03-05 23:37     ` Alastair D'Silva
2020-03-04  6:53   ` Andrew Donnellan
2020-03-06  3:34     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 19/27] powerpc/powernv/pmem: Add an IOCTL to report controller statistics Alastair D'Silva
2020-03-04  9:25   ` Frederic Barrat [this message]
2020-03-12  0:15     ` Alastair D'Silva
2020-03-05  0:46   ` Andrew Donnellan
2020-03-12  4:47     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 20/27] powerpc/powernv/pmem: Forward events to userspace Alastair D'Silva
2020-03-03  7:02   ` Andrew Donnellan
2020-03-04  5:48     ` Alastair D'Silva
2020-03-04 11:00   ` Frederic Barrat
2020-03-11  3:32     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 21/27] powerpc/powernv/pmem: Add an IOCTL to request controller health & perf data Alastair D'Silva
2020-02-28  6:12   ` Andrew Donnellan
2020-03-02  5:40     ` Alastair D'Silva
2020-03-04 11:06     ` Frederic Barrat
2020-03-11  3:38       ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 22/27] powerpc/powernv/pmem: Implement the heartbeat command Alastair D'Silva
2020-02-28  6:20   ` Andrew Donnellan
2020-03-04 14:25   ` Frederic Barrat
2020-02-21  3:27 ` [PATCH v3 23/27] powerpc/powernv/pmem: Add debug IOCTLs Alastair D'Silva
2020-03-04 15:21   ` Frederic Barrat
2020-03-12  4:24     ` Alastair D'Silva
2020-03-05  3:11   ` Andrew Donnellan
2020-03-12  4:58     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 24/27] powerpc/powernv/pmem: Expose SMART data via ndctl Alastair D'Silva
2020-03-04 15:40   ` Frederic Barrat
2020-03-05  3:36   ` Andrew Donnellan
2020-03-12 23:14     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 25/27] powerpc/powernv/pmem: Expose the serial number in sysfs Alastair D'Silva
2020-02-28  6:25   ` Andrew Donnellan
2020-02-28  7:15     ` Greg Kroah-Hartman
2020-03-01 23:42       ` Alastair D'Silva
2020-03-02  5:38         ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 26/27] powerpc/powernv/pmem: Expose the firmware version " Alastair D'Silva
2020-03-02  7:35   ` Andrew Donnellan
2020-03-04  4:11     ` Alastair D'Silva
2020-02-21  3:27 ` [PATCH v3 27/27] MAINTAINERS: Add myself & nvdimm/ocxl to ocxl Alastair D'Silva
2020-02-21  5:35   ` Andrew Donnellan
2020-02-21 16:21 ` [PATCH v3 00/27] Add support for OpenCAPI Persistent Memory devices Dan Williams
2020-02-21 16:24   ` Dan Williams
2020-02-24  4:34   ` Alastair D'Silva
2020-02-24  4:37     ` Matthew Wilcox
2020-02-24  4:42       ` Alastair D'Silva
2020-02-24  6:51         ` Oliver O'Halloran
2020-02-26  0:13           ` Alastair D'Silva
2020-02-26  0:32             ` Dan Williams
2020-02-26  0:35               ` Alastair D'Silva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6ee036c7-f4ea-4e42-faad-66a1921553ce@linux.ibm.com \
    --to=fbarrat@linux.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=ajd@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alastair@au1.ibm.com \
    --cc=alastair@d-silva.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=anju@linux.vnet.ibm.com \
    --cc=anton@ozlabs.org \
    --cc=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=clg@kaod.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=groug@kaod.org \
    --cc=hbathini@linux.ibm.com \
    --cc=ira.weiny@intel.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.vnet.ibm.com \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=oohall@gmail.com \
    --cc=paulus@samba.org \
    --cc=robh@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vishal.l.verma@intel.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).