From: Alison Schofield <alison.schofield@intel.com>
To: Li Ming <ming.li@zohomail.com>
Cc: nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org
Subject: Re: [ndctl PATCH 1/1] daxctl: Output more information if memblock is unremovable
Date: Sat, 8 Feb 2025 17:46:28 -0800 [thread overview]
Message-ID: <Z6gI9AI5slmNc7S2@aschofie-mobl2.lan> (raw)
In-Reply-To: <20241204161457.1113419-1-ming.li@zohomail.com>
On Thu, Dec 05, 2024 at 12:14:56AM +0800, Li Ming wrote:
> If CONFIG_MEMORY_HOTREMOVE is disabled by kernel, memblocks will not be
> removed, so 'dax offline-memory all' will output below error logs:
>
> libdaxctl: offline_one_memblock: dax0.0: Failed to offline /sys/devices/system/node/node6/memory371/state: Invalid argument
> dax0.0: failed to offline memory: Invalid argument
> error offlining memory: Invalid argument
> offlined memory for 0 devices
>
> The log does not clearly show why the command failed. So checking if the
> target memblock is removable before offlining it by querying
> '/sys/devices/system/node/nodeX/memoryY/removable', then output specific
> logs if the memblock is unremovable, output will be:
>
> libdaxctl: offline_one_memblock: dax0.0: memory371 is unremovable
> dax0.0: failed to offline memory: Operation not supported
> error offlining memory: Operation not supported
> offlined memory for 0 devices
>
> Besides, delay to set up string 'path' for offlining memblock operation,
> because string 'path' is stored in 'mem->mem_buf' which is a shared
> buffer, it will be used in memblock_is_removable().
>
> Signed-off-by: Li Ming <ming.li@zohomail.com>
> ---
Hi Ming,
I was looking to merge this today but realized that I only have
a test for it in the 'affirmative'. The ndctl:dax unit tests exercise
this path, but since nfit-test module requires CONFIG_MEMORY_HOTREMOVE
I could only prove that this works one way. I put in some printfs and
saw it in action:
libdaxctl: memblock_is_removable: Ming: memblock_is_removable()
libdaxctl: offline_one_memblock: Ming: return from memblock_is_removable()
Let's get another reviewer eyes on this before merging.
Also, if you can add your qemu (i'm guessing) demo that would be helpful.
Also, we were having discussions about exposing more info to user, but I
think that can be a follow on. You can propose that it another patch after
this one, if you think it is worthwhile.
snip
next prev parent reply other threads:[~2025-02-09 1:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-04 16:14 [ndctl PATCH 1/1] daxctl: Output more information if memblock is unremovable Li Ming
2024-12-06 1:10 ` Alison Schofield
2024-12-06 7:06 ` Li Ming
2024-12-11 7:30 ` Li Ming
2025-01-08 16:46 ` Dave Jiang
2025-01-09 0:58 ` Li Ming
2025-01-09 15:06 ` Dave Jiang
2025-02-09 1:46 ` Alison Schofield [this message]
2025-03-03 20:04 ` Alison Schofield
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=Z6gI9AI5slmNc7S2@aschofie-mobl2.lan \
--to=alison.schofield@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=ming.li@zohomail.com \
--cc=nvdimm@lists.linux.dev \
/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