linux-cxl.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Dave Jiang <dave.jiang@intel.com>, <linux-cxl@vger.kernel.org>
Cc: <dave@stgolabs.net>, <jonathan.cameron@huawei.com>,
	<alison.schofield@intel.com>, <vishal.l.verma@intel.com>,
	<ira.weiny@intel.com>, <dan.j.williams@intel.com>
Subject: RE: [PATCH v3] cxl: Add committed sysfs attribute to CXL decoder
Date: Tue, 3 Oct 2023 15:40:07 -0700	[thread overview]
Message-ID: <651c98472dfed_ae7e729495@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <169575398814.4028282.11591056324662123995.stgit@djiang5-mobl3>

Dave Jiang wrote:
> This attribute allows cxl-cli to determine whether a decoder is
> actively participating in a region. This is only a snapshot of the
> state, and doesn't offer any protection or serialization against a
> concurrent disable-region operation.

A random thought occurred while realizing that the kernel uses a check
of:

    port->commit_end != -1

...to determine that a given port (switch or endpoint) has committed
decoders. If the goal here is to determine when it is safe to disable an
entire memdev maybe it is better to check all of the decoders at once at
the port level rather than one at a time. It is already the case that
CXL prevents decoders from being committed out of order so what do you
think of replacing decoderX.Y/committed with portX/decoders_committed,
where it just does:

    down_read(&cxl_region_rwsem);
    sysfs_emit("%d\n", port->commit_end + 1);
    up_read(&cxl_region_rwsem);

...and cxl-cli aborts destructive processes on that attribute being
non-zero.

Is there any use case for userspace to check for individual decoders
being committed? It can infer "decoder committed" from "decoder_id <
decoders_commited".

  parent reply	other threads:[~2023-10-03 22:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 18:46 [PATCH v3] cxl: Add committed sysfs attribute to CXL decoder Dave Jiang
2023-09-28  1:15 ` Davidlohr Bueso
2023-10-03 22:40 ` Dan Williams [this message]
2023-10-03 23:23   ` Dave Jiang

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=651c98472dfed_ae7e729495@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=alison.schofield@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stgolabs.net \
    --cc=ira.weiny@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=vishal.l.verma@intel.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).