linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: <shiju.jose@huawei.com>
Cc: <linux-cxl@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
	<linux-mm@kvack.org>, <dan.j.williams@intel.com>,
	<dave@stgolabs.net>, <dave.jiang@intel.com>,
	<alison.schofield@intel.com>, <vishal.l.verma@intel.com>,
	<ira.weiny@intel.com>, <linux-edac@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <david@redhat.com>,
	<Vilas.Sridharan@amd.com>, <leo.duran@amd.com>,
	<Yazen.Ghannam@amd.com>, <rientjes@google.com>,
	<jiaqiyan@google.com>, <tony.luck@intel.com>, <Jon.Grimm@amd.com>,
	<dave.hansen@linux.intel.com>, <rafael@kernel.org>,
	<lenb@kernel.org>, <naoya.horiguchi@nec.com>,
	<james.morse@arm.com>, <jthoughton@google.com>,
	<somasundaram.a@hpe.com>, <erdemaktas@google.com>,
	<pgonda@google.com>, <duenwen@google.com>,
	<mike.malvestuto@intel.com>, <gthelen@google.com>,
	<wschwartz@amperecomputing.com>, <dferguson@amperecomputing.com>,
	<tanxiaofei@huawei.com>, <prime.zeng@hisilicon.com>,
	<kangkang.shen@futurewei.com>, <wanghuiqiang@huawei.com>,
	<linuxarm@huawei.com>
Subject: Re: [RFC PATCH v6 08/12] cxl/memscrub: Register CXL device ECS with scrub configure driver
Date: Tue, 20 Feb 2024 13:39:55 +0000	[thread overview]
Message-ID: <20240220133955.0000710b@Huawei.com> (raw)
In-Reply-To: <20240215111455.1462-9-shiju.jose@huawei.com>

On Thu, 15 Feb 2024 19:14:50 +0800
<shiju.jose@huawei.com> wrote:

> From: Shiju Jose <shiju.jose@huawei.com>
> 
> Register with the scrub configure driver to expose the sysfs attributes
> to the user for configuring the CXL memory device's ECS feature.
> Add the static CXL ECS specific attributes to support configuring the
> CXL memory device ECS feature.
> 
> Signed-off-by: Shiju Jose <shiju.jose@huawei.com>

The ABI in here needs documentation.  My key takeaway is that
it is very ECS specific.  I think one of the big challenges of a common scrub
control system is going to be trying to come up with some meaningful 
common ABI.

> ---
>  drivers/cxl/core/memscrub.c | 253 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 250 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cxl/core/memscrub.c b/drivers/cxl/core/memscrub.c
> index a1fb40f8307f..325084b22e7a 100644
> --- a/drivers/cxl/core/memscrub.c
> +++ b/drivers/cxl/core/memscrub.c
> @@ -464,6 +464,8 @@ EXPORT_SYMBOL_NS_GPL(cxl_mem_patrol_scrub_init, CXL);
>  #define CXL_MEMDEV_ECS_GET_FEAT_VERSION	0x01
>  #define CXL_MEMDEV_ECS_SET_FEAT_VERSION	0x01
>  
> +#define CXL_DDR5_ECS	"cxl_ecs"
I would just put these name defines inline.

> +enum cxl_mem_ecs_scrub_attributes {
> +	cxl_ecs_log_entry_type,
> +	cxl_ecs_log_entry_type_per_dram,
> +	cxl_ecs_log_entry_type_per_memory_media,
> +	cxl_ecs_mode,
> +	cxl_ecs_mode_counts_codewords,
> +	cxl_ecs_mode_counts_rows,
> +	cxl_ecs_reset,
> +	cxl_ecs_threshold,
> +	cxl_ecs_threshold_available,
> +	cxl_ecs_max_attrs,
This is pretty much all custom ABI.  Challenging to make it common with
the main scrub and RASF controls, but I think we do need to see if we can
come up with something that is at least vaguely consistent across
different forms of scrub control.

What the user cares about is how likely an error is to get past the
scrubbing that is running (I think - RAS folk speak up if I have
this wrong!)

So how do we go from the ECS parameters to that sort of info?
I think ECS is effectively scrubbing at a fixed rate (google suggests
all ram every 24 hours).  We are really controlling what info is
reported rather than what scrub is carried out.

Useful stuff to potentially control but different from the
other cases.


> +};

> +
>  int cxl_mem_ecs_init(struct cxl_memdev *cxlmd, int region_id)
>  {
> +	char scrub_name[CXL_MEMDEV_MAX_NAME_LENGTH];
>  	struct cxl_mbox_supp_feat_entry feat_entry;
>  	struct cxl_ecs_context *cxl_ecs_ctx;
> +	struct device *cxl_scrub_dev;

Make this more local as we don't need it out here?

>  	int nmedia_frus;
>  	int ret;
>  
> @@ -755,6 +993,15 @@ int cxl_mem_ecs_init(struct cxl_memdev *cxlmd, int region_id)
>  		cxl_ecs_ctx->get_feat_size = feat_entry.get_feat_size;
>  		cxl_ecs_ctx->set_feat_size = feat_entry.set_feat_size;
>  		cxl_ecs_ctx->region_id = region_id;
> +
> +		snprintf(scrub_name, sizeof(scrub_name), "%s_%s_region%d",
> +			 CXL_DDR5_ECS, dev_name(&cxlmd->dev), cxl_ecs_ctx->region_id);
> +		cxl_scrub_dev = devm_scrub_device_register(&cxlmd->dev, scrub_name,
> +							  cxl_ecs_ctx, NULL,
> +							  cxl_ecs_ctx->region_id,
> +							  &cxl_mem_ecs_attr_group);
> +		if (IS_ERR(cxl_scrub_dev))
> +			return PTR_ERR(cxl_scrub_dev);
>  	}
>  
>  	return 0;


  reply	other threads:[~2024-02-20 13:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 11:14 [RFC PATCH v6 00/12] cxl: Add support for CXL feature commands, CXL device patrol scrub control and DDR5 ECS control features shiju.jose
2024-02-15 11:14 ` [RFC PATCH v6 01/12] cxl/mbox: Add GET_SUPPORTED_FEATURES mailbox command shiju.jose
2024-02-20 11:02   ` Jonathan Cameron
2024-03-05 23:57   ` fan
2024-02-15 11:14 ` [RFC PATCH v6 02/12] cxl/mbox: Add GET_FEATURE " shiju.jose
2024-02-20 11:14   ` Jonathan Cameron
2024-02-23 12:23     ` Shiju Jose
2024-02-15 11:14 ` [RFC PATCH v6 03/12] cxl/mbox: Add SET_FEATURE " shiju.jose
2024-02-20 11:27   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 04/12] cxl/memscrub: Add CXL device patrol scrub control feature shiju.jose
2024-02-20 11:59   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 05/12] cxl/memscrub: Add CXL device ECS " shiju.jose
2024-02-20 12:17   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 06/12] memory: scrub: Add scrub subsystem driver supports configuring memory scrubs in the system shiju.jose
2024-02-20 12:39   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 07/12] cxl/memscrub: Register CXL device patrol scrub with scrub configure driver shiju.jose
2024-02-20 12:43   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 08/12] cxl/memscrub: Register CXL device ECS " shiju.jose
2024-02-20 13:39   ` Jonathan Cameron [this message]
2024-02-15 11:14 ` [RFC PATCH v6 09/12] ACPI:RASF: Add common library for RASF and RAS2 PCC interfaces shiju.jose
2024-02-20 13:53   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 10/12] ACPICA: ACPI 6.5: Add support for RAS2 table shiju.jose
2024-02-20 13:58   ` Jonathan Cameron
2024-02-15 11:14 ` [RFC PATCH v6 11/12] ACPI:RAS2: Add driver for ACPI RAS2 feature table (RAS2) shiju.jose
2024-02-15 11:14 ` [RFC PATCH v6 12/12] memory: RAS2: Add memory RAS2 driver shiju.jose
2024-02-20 16:12   ` Jonathan Cameron
2024-02-22  0:20 ` [RFC PATCH v6 00/12] cxl: Add support for CXL feature commands, CXL device patrol scrub control and DDR5 ECS control features Dan Williams
2024-02-23 12:16   ` Shiju Jose
2024-02-23 19:42     ` Dan Williams
2024-02-26 10:29       ` Jonathan Cameron
2024-02-29 19:51         ` Dan Williams
2024-03-01 14:41           ` Jonathan Cameron
2024-03-05  0:52             ` Jiaqi Yan
2024-02-29 20:41         ` Tony Luck
2024-03-01 13:19           ` Jonathan Cameron
2024-02-28 22:26       ` John Groves

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=20240220133955.0000710b@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Jon.Grimm@amd.com \
    --cc=Vilas.Sridharan@amd.com \
    --cc=Yazen.Ghannam@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=david@redhat.com \
    --cc=dferguson@amperecomputing.com \
    --cc=duenwen@google.com \
    --cc=erdemaktas@google.com \
    --cc=gthelen@google.com \
    --cc=ira.weiny@intel.com \
    --cc=james.morse@arm.com \
    --cc=jiaqiyan@google.com \
    --cc=jthoughton@google.com \
    --cc=kangkang.shen@futurewei.com \
    --cc=lenb@kernel.org \
    --cc=leo.duran@amd.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxarm@huawei.com \
    --cc=mike.malvestuto@intel.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=pgonda@google.com \
    --cc=prime.zeng@hisilicon.com \
    --cc=rafael@kernel.org \
    --cc=rientjes@google.com \
    --cc=shiju.jose@huawei.com \
    --cc=somasundaram.a@hpe.com \
    --cc=tanxiaofei@huawei.com \
    --cc=tony.luck@intel.com \
    --cc=vishal.l.verma@intel.com \
    --cc=wanghuiqiang@huawei.com \
    --cc=wschwartz@amperecomputing.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).