Correctable memory errors are very common on servers with large amount of memory, and are corrected by ECC, but with two pain points to users: 1. Correction usually happens on the fly and adds latency overhead 2. Not-fully-proved theory states excessive correctable memory errors can develop into uncorrectable memory error.
Soft offline is kernel's additional solution for memory pages having (excessive) corrected memory errors. Impacted page is migrated to healthy page if it is in use, then the original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be maintained by userspace, especially in case of an 1G HugeTLB page. Soft-offline dissolves the HugeTLB page, either in-use or free, into chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If userspace has not acknowledged such behavior, it may be surprised when later mmap hugepages MAP_FAILED due to lack of hugepages. In case of a transparent hugepage, it will be split into 4K pages as well; userspace will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of corrected memory errors sounds very costly and kernel better not doing under the hood. But today there are at least 2 such cases: 1. GHES driver sees both GHES_SEV_CORRECTED and CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER. 2. RAS Correctable Errors Collector counts correctable errors per PFN and when the counter for a PFN reaches threshold In both cases, userspace has no control of the soft offline performed by kernel's memory failure recovery.
This patch series give userspace the control of softofflining any page: kernel only soft offlines raw page / transparent hugepage / HugeTLB hugepage if userspace has agreed to. The interface to userspace is a new sysctl called enable_soft_offline under /proc/sys/vm. By default enable_soft_line is 1 to preserve existing behavior in kernel.
Changelog
v2 => v3: * incorporate feedbacks from Miaohe Lin linmiaohe@huawei.come, Lance Yang ioworker0@gmail.com, Oscar Salvador osalvador@suse.de, and David Rientjes rientjes@google.com. * release potential refcount if enable_soft_offline is 0. * soft_offline_page() returns EOPNOTSUPP if enable_soft_offline is 0. * refactor hugetlb-soft-offline.c, for example, introduce test_soft_offline_common to reduce repeated code. * rewrite enable_soft_offline's documentation, adds more details about the cost of soft-offline for transparent and hugetlb hugepages, and components that are impacted when enable_soft_offline becomes 0. * fix typos in commit messages. * v3 is still based on commit 83a7eefedc9b ("Linux 6.10-rc3").
v1 => v2: * incorporate feedbacks from both Miaohe Lin linmiaohe@huawei.com and Jane Chu jane.chu@oracle.com. * make the switch to control all pages, instead of HugeTLB specific. * change the API from /sys/kernel/mm/hugepages/hugepages-${size}kB/softoffline_corrected_errors to /proc/sys/vm/enable_soft_offline. * minor update to test code. * update documentation of the user control API. * v2 is based on commit 83a7eefedc9b ("Linux 6.10-rc3").
Jiaqi Yan (3): mm/memory-failure: userspace controls soft-offlining pages selftest/mm: test enable_soft_offline behaviors docs: mm: add enable_soft_offline sysctl
Documentation/admin-guide/sysctl/vm.rst | 33 +++ mm/memory-failure.c | 22 +- tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + .../selftests/mm/hugetlb-soft-offline.c | 229 ++++++++++++++++++ tools/testing/selftests/mm/run_vmtests.sh | 4 + 6 files changed, 288 insertions(+), 2 deletions(-) create mode 100644 tools/testing/selftests/mm/hugetlb-soft-offline.c
Correctable memory errors are very common on servers with large amount of memory, and are corrected by ECC. Soft offline is kernel's additional recovery handling for memory pages having (excessive) corrected memory errors. Impacted page is migrated to a healthy page if it is in-use; the original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be maintained by userspace, especially in case of an 1G HugeTLB page. Soft-offline dissolves the HugeTLB page, either in-use or free, into chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If userspace has not acknowledged such behavior, it may be surprised when later failed to mmap hugepages due to lack of hugepages. In case of a transparent hugepage, it will be split into 4K pages as well; userspace will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of corrected memory errors sounds very costly and kernel better not doing under the hood. But today there are at least 2 such cases doing so: 1. GHES driver sees both GHES_SEV_CORRECTED and CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER. 2. RAS Correctable Errors Collector counts correctable errors per PFN and when the counter for a PFN reaches threshold In both cases, userspace has no control of the soft offline performed by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel only soft offlines raw page / transparent hugepage / HugeTLB hugepage if userspace has agreed to. The interface to userspace is a new sysctl at /proc/sys/vm/enable_soft_offline. By default its value is set to 1 to preserve existing behavior in kernel. When set to 0, soft-offline (e.g. MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
Signed-off-by: Jiaqi Yan jiaqiyan@google.com --- mm/memory-failure.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c index d3c830e817e3..9eb216ed0b86 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -68,6 +68,8 @@ static int sysctl_memory_failure_early_kill __read_mostly;
static int sysctl_memory_failure_recovery __read_mostly = 1;
+static int sysctl_enable_soft_offline __read_mostly = 1; + atomic_long_t num_poisoned_pages __read_mostly = ATOMIC_LONG_INIT(0);
static bool hw_memory_failure __read_mostly = false; @@ -141,6 +143,15 @@ static struct ctl_table memory_failure_table[] = { .extra1 = SYSCTL_ZERO, .extra2 = SYSCTL_ONE, }, + { + .procname = "enable_soft_offline", + .data = &sysctl_enable_soft_offline, + .maxlen = sizeof(sysctl_enable_soft_offline), + .mode = 0644, + .proc_handler = proc_dointvec_minmax, + .extra1 = SYSCTL_ZERO, + .extra2 = SYSCTL_ONE, + } };
/* @@ -2746,8 +2757,9 @@ static int soft_offline_in_use_page(struct page *page) * @pfn: pfn to soft-offline * @flags: flags. Same as memory_failure(). * - * Returns 0 on success - * -EOPNOTSUPP for hwpoison_filter() filtered the error event + * Returns 0 on success, + * -EOPNOTSUPP for hwpoison_filter() filtered the error event, + * -EOPNOTSUPP if disabled by /proc/sys/vm/enable_soft_offline, * < 0 otherwise negated errno. * * Soft offline a page, by migration or invalidation, @@ -2783,6 +2795,12 @@ int soft_offline_page(unsigned long pfn, int flags) return -EIO; }
+ if (!sysctl_enable_soft_offline) { + pr_info("%#lx: OS-wide disabled\n", pfn); + put_ref_page(pfn, flags); + return -EOPNOTSUPP; + } + mutex_lock(&mf_mutex);
if (PageHWPoison(page)) {
On Mon, 17 Jun 2024 17:05:43 +0000 Jiaqi Yan jiaqiyan@google.com wrote:
Correctable memory errors are very common on servers with large amount of memory, and are corrected by ECC. Soft offline is kernel's additional recovery handling for memory pages having (excessive) corrected memory errors. Impacted page is migrated to a healthy page if it is in-use; the original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be maintained by userspace, especially in case of an 1G HugeTLB page. Soft-offline dissolves the HugeTLB page, either in-use or free, into chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If userspace has not acknowledged such behavior, it may be surprised when later failed to mmap hugepages due to lack of hugepages. In case of a transparent hugepage, it will be split into 4K pages as well; userspace will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of corrected memory errors sounds very costly and kernel better not doing under the hood. But today there are at least 2 such cases doing so:
- GHES driver sees both GHES_SEV_CORRECTED and CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
- RAS Correctable Errors Collector counts correctable errors per PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel only soft offlines raw page / transparent hugepage / HugeTLB hugepage if userspace has agreed to. The interface to userspace is a new sysctl at /proc/sys/vm/enable_soft_offline. By default its value is set to 1 to preserve existing behavior in kernel. When set to 0, soft-offline (e.g. MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
Seems reasonable. A very simple patch.
Is there sufficient instrumentation in place for userspace to be able to know that these errors are occurring? To be able to generally monitor the machine's health?
@@ -2783,6 +2795,12 @@ int soft_offline_page(unsigned long pfn, int flags) return -EIO; }
- if (!sysctl_enable_soft_offline) {
pr_info("%#lx: OS-wide disabled\n", pfn);
This doesn't seem a very good message. There's no indication that it comes from the memory failure code at all. If the sysadmin sees this come out in the kernels logs, he/she will have to grep the kernel sources just to figure out where the message came from. Perhaps we can be more helpful here..
put_ref_page(pfn, flags);
return -EOPNOTSUPP;
- }
- mutex_lock(&mf_mutex);
On Mon, Jun 17, 2024 at 12:13 PM Andrew Morton akpm@linux-foundation.org wrote:
On Mon, 17 Jun 2024 17:05:43 +0000 Jiaqi Yan jiaqiyan@google.com wrote:
Correctable memory errors are very common on servers with large amount of memory, and are corrected by ECC. Soft offline is kernel's additional recovery handling for memory pages having (excessive) corrected memory errors. Impacted page is migrated to a healthy page if it is in-use; the original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be maintained by userspace, especially in case of an 1G HugeTLB page. Soft-offline dissolves the HugeTLB page, either in-use or free, into chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If userspace has not acknowledged such behavior, it may be surprised when later failed to mmap hugepages due to lack of hugepages. In case of a transparent hugepage, it will be split into 4K pages as well; userspace will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of corrected memory errors sounds very costly and kernel better not doing under the hood. But today there are at least 2 such cases doing so:
- GHES driver sees both GHES_SEV_CORRECTED and CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
- RAS Correctable Errors Collector counts correctable errors per PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel only soft offlines raw page / transparent hugepage / HugeTLB hugepage if userspace has agreed to. The interface to userspace is a new sysctl at /proc/sys/vm/enable_soft_offline. By default its value is set to 1 to preserve existing behavior in kernel. When set to 0, soft-offline (e.g. MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
Seems reasonable. A very simple patch.
Thanks for taking a look, Andrew!
Is there sufficient instrumentation in place for userspace to be able to know that these errors are occurring? To be able to generally monitor the machine's health?
For corrected memory errors, in general they are available in kernel logs. On X86 Machine Check handling will log unparsed MCs (one needs to read mci_status to know what exactly the error is). On ARM, GHES logs parsed CPER (already containing error type and error severity). The shortcoming is logs are rate limited. So in a burst of corrected memory errors the user may not be able to figure out exactly how many there were.
For uncorrectable memory errors, num_poisoned_pages is a reliable counter.
@@ -2783,6 +2795,12 @@ int soft_offline_page(unsigned long pfn, int flags) return -EIO; }
if (!sysctl_enable_soft_offline) {
pr_info("%#lx: OS-wide disabled\n", pfn);
This doesn't seem a very good message. There's no indication that it comes from the memory failure code at all. If the sysadmin sees this come out in the kernels logs, he/she will have to grep the kernel sources just to figure out where the message came from. Perhaps we can be more helpful here..
For sure. I took it for granted that any pr_info will have the "Memory failure: " prefix, but now realize there is a `#undef pr_fmt` + `#define pr_fmt(fmt) "" fmt` just above unpoison_memory.
I propose to do `#define pr_fmt(fmt) "Soft offline: " fmt` above mf_isolate_folio, so that any soft-offline related code generates logs with the same following format:
"Soft offline: 0x${pfn}: ${detailed_message}"
If everyone thinks this is reasonable, in v4 I can insert a new commit to make the log formats unified.
put_ref_page(pfn, flags);
return -EOPNOTSUPP;
}
mutex_lock(&mf_mutex);
On 2024/6/18 7:17, Jiaqi Yan wrote:
On Mon, Jun 17, 2024 at 12:13 PM Andrew Morton akpm@linux-foundation.org wrote:
On Mon, 17 Jun 2024 17:05:43 +0000 Jiaqi Yan jiaqiyan@google.com wrote:
Correctable memory errors are very common on servers with large amount of memory, and are corrected by ECC. Soft offline is kernel's additional recovery handling for memory pages having (excessive) corrected memory errors. Impacted page is migrated to a healthy page if it is in-use; the original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be maintained by userspace, especially in case of an 1G HugeTLB page. Soft-offline dissolves the HugeTLB page, either in-use or free, into chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If userspace has not acknowledged such behavior, it may be surprised when later failed to mmap hugepages due to lack of hugepages. In case of a transparent hugepage, it will be split into 4K pages as well; userspace will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of corrected memory errors sounds very costly and kernel better not doing under the hood. But today there are at least 2 such cases doing so:
- GHES driver sees both GHES_SEV_CORRECTED and CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
- RAS Correctable Errors Collector counts correctable errors per PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel only soft offlines raw page / transparent hugepage / HugeTLB hugepage if userspace has agreed to. The interface to userspace is a new sysctl at /proc/sys/vm/enable_soft_offline. By default its value is set to 1 to preserve existing behavior in kernel. When set to 0, soft-offline (e.g. MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
Seems reasonable. A very simple patch.
Thanks for taking a look, Andrew!
Is there sufficient instrumentation in place for userspace to be able to know that these errors are occurring? To be able to generally monitor the machine's health?
For corrected memory errors, in general they are available in kernel logs. On X86 Machine Check handling will log unparsed MCs (one needs to read mci_status to know what exactly the error is). On ARM, GHES logs parsed CPER (already containing error type and error severity). The shortcoming is logs are rate limited. So in a burst of corrected memory errors the user may not be able to figure out exactly how many there were.
For uncorrectable memory errors, num_poisoned_pages is a reliable counter.
@@ -2783,6 +2795,12 @@ int soft_offline_page(unsigned long pfn, int flags) return -EIO; }
if (!sysctl_enable_soft_offline) {
pr_info("%#lx: OS-wide disabled\n", pfn);
This doesn't seem a very good message. There's no indication that it comes from the memory failure code at all. If the sysadmin sees this come out in the kernels logs, he/she will have to grep the kernel sources just to figure out where the message came from. Perhaps we can be more helpful here..
For sure. I took it for granted that any pr_info will have the "Memory failure: " prefix, but now realize there is a `#undef pr_fmt` + `#define pr_fmt(fmt) "" fmt` just above unpoison_memory.
I propose to do `#define pr_fmt(fmt) "Soft offline: " fmt` above mf_isolate_folio, so that any soft-offline related code generates logs with the same following format:
"Soft offline: 0x${pfn}: ${detailed_message}"
If everyone thinks this is reasonable, in v4 I can insert a new commit to make the log formats unified.
This sounds fine to me. And even better, `#define pr_fmt(fmt) "Unpoison: " fmt` can also be done just above unpoison_memory.
Thanks. .
On Mon, Jun 17, 2024 at 8:01 PM Miaohe Lin linmiaohe@huawei.com wrote:
On 2024/6/18 7:17, Jiaqi Yan wrote:
On Mon, Jun 17, 2024 at 12:13 PM Andrew Morton akpm@linux-foundation.org wrote:
On Mon, 17 Jun 2024 17:05:43 +0000 Jiaqi Yan jiaqiyan@google.com wrote:
Correctable memory errors are very common on servers with large amount of memory, and are corrected by ECC. Soft offline is kernel's additional recovery handling for memory pages having (excessive) corrected memory errors. Impacted page is migrated to a healthy page if it is in-use; the original page is discarded for any future use.
The actual policy on whether (and when) to soft offline should be maintained by userspace, especially in case of an 1G HugeTLB page. Soft-offline dissolves the HugeTLB page, either in-use or free, into chunks of 4K pages, reducing HugeTLB pool capacity by 1 hugepage. If userspace has not acknowledged such behavior, it may be surprised when later failed to mmap hugepages due to lack of hugepages. In case of a transparent hugepage, it will be split into 4K pages as well; userspace will stop enjoying the transparent performance.
In addition, discarding the entire 1G HugeTLB page only because of corrected memory errors sounds very costly and kernel better not doing under the hood. But today there are at least 2 such cases doing so:
- GHES driver sees both GHES_SEV_CORRECTED and CPER_SEC_ERROR_THRESHOLD_EXCEEDED after parsing CPER.
- RAS Correctable Errors Collector counts correctable errors per PFN and when the counter for a PFN reaches threshold
In both cases, userspace has no control of the soft offline performed by kernel's memory failure recovery.
This commit gives userspace the control of softofflining any page: kernel only soft offlines raw page / transparent hugepage / HugeTLB hugepage if userspace has agreed to. The interface to userspace is a new sysctl at /proc/sys/vm/enable_soft_offline. By default its value is set to 1 to preserve existing behavior in kernel. When set to 0, soft-offline (e.g. MADV_SOFT_OFFLINE) will fail with EOPNOTSUPP.
Seems reasonable. A very simple patch.
Thanks for taking a look, Andrew!
Is there sufficient instrumentation in place for userspace to be able to know that these errors are occurring? To be able to generally monitor the machine's health?
For corrected memory errors, in general they are available in kernel logs. On X86 Machine Check handling will log unparsed MCs (one needs to read mci_status to know what exactly the error is). On ARM, GHES logs parsed CPER (already containing error type and error severity). The shortcoming is logs are rate limited. So in a burst of corrected memory errors the user may not be able to figure out exactly how many there were.
For uncorrectable memory errors, num_poisoned_pages is a reliable counter.
@@ -2783,6 +2795,12 @@ int soft_offline_page(unsigned long pfn, int flags) return -EIO; }
if (!sysctl_enable_soft_offline) {
pr_info("%#lx: OS-wide disabled\n", pfn);
This doesn't seem a very good message. There's no indication that it comes from the memory failure code at all. If the sysadmin sees this come out in the kernels logs, he/she will have to grep the kernel sources just to figure out where the message came from. Perhaps we can be more helpful here..
For sure. I took it for granted that any pr_info will have the "Memory failure: " prefix, but now realize there is a `#undef pr_fmt` + `#define pr_fmt(fmt) "" fmt` just above unpoison_memory.
I propose to do `#define pr_fmt(fmt) "Soft offline: " fmt` above mf_isolate_folio, so that any soft-offline related code generates logs with the same following format:
"Soft offline: 0x${pfn}: ${detailed_message}"
If everyone thinks this is reasonable, in v4 I can insert a new commit to make the log formats unified.
This sounds fine to me. And even better, `#define pr_fmt(fmt) "Unpoison: " fmt` can also be done just above unpoison_memory.
Of course. I just sent out a standalone patch for unpoison_memory to you.
Thanks. .
On Mon, Jun 17, 2024 at 05:05:43PM +0000, Jiaqi Yan wrote:
- Returns 0 on success
-EOPNOTSUPP for hwpoison_filter() filtered the error event
- Returns 0 on success,
-EOPNOTSUPP for hwpoison_filter() filtered the error event,
-EOPNOTSUPP if disabled by /proc/sys/vm/enable_soft_offline,
< 0 otherwise negated errno.
- Soft offline a page, by migration or invalidation,
@@ -2783,6 +2795,12 @@ int soft_offline_page(unsigned long pfn, int flags) return -EIO; }
- if (!sysctl_enable_soft_offline) {
pr_info("%#lx: OS-wide disabled\n", pfn);
put_ref_page(pfn, flags);
return -EOPNOTSUPP;
- }
We should not be doing anything if soft_offline is disabled, so this check should be placed upfront, at the very beginning of the function. Then you can remove the 'put_ref_page' call.
On Wed, Jun 19, 2024 at 07:03:46AM +0200, Oscar Salvador wrote:
On Mon, Jun 17, 2024 at 05:05:43PM +0000, Jiaqi Yan wrote:
- if (!sysctl_enable_soft_offline) {
pr_info("%#lx: OS-wide disabled\n", pfn);
put_ref_page(pfn, flags);
return -EOPNOTSUPP;
- }
We should not be doing anything if soft_offline is disabled, so this check should be placed upfront, at the very beginning of the function. Then you can remove the 'put_ref_page' call.
Also, I would go for a pr_info_once here, as otherwise we can spam the log quite easy.
On Tue, Jun 18, 2024 at 10:13 PM Oscar Salvador osalvador@suse.de wrote:
On Wed, Jun 19, 2024 at 07:03:46AM +0200, Oscar Salvador wrote:
On Mon, Jun 17, 2024 at 05:05:43PM +0000, Jiaqi Yan wrote:
- if (!sysctl_enable_soft_offline) {
pr_info("%#lx: OS-wide disabled\n", pfn);
put_ref_page(pfn, flags);
return -EOPNOTSUPP;
- }
We should not be doing anything if soft_offline is disabled, so this check should be placed upfront, at the very beginning of the function. Then you can remove the 'put_ref_page' call.
Also, I would go for a pr_info_once here, as otherwise we can spam the log quite easy.
Nice catch. I will do pr_info_once in v4.
-- Oscar Salvador SUSE Labs
On Wed, Jun 19, 2024 at 07:03:46AM +0200, Oscar Salvador wrote:
We should not be doing anything if soft_offline is disabled, so this check should be placed upfront, at the very beginning of the function. Then you can remove the 'put_ref_page' call.
Sorry, I managed to confuse myself, this has to stay as is.
On Tue, Jun 18, 2024 at 10:03 PM Oscar Salvador osalvador@suse.de wrote:
On Mon, Jun 17, 2024 at 05:05:43PM +0000, Jiaqi Yan wrote:
- Returns 0 on success
-EOPNOTSUPP for hwpoison_filter() filtered the error event
- Returns 0 on success,
-EOPNOTSUPP for hwpoison_filter() filtered the error event,
-EOPNOTSUPP if disabled by /proc/sys/vm/enable_soft_offline,
< 0 otherwise negated errno.
- Soft offline a page, by migration or invalidation,
@@ -2783,6 +2795,12 @@ int soft_offline_page(unsigned long pfn, int flags) return -EIO; }
if (!sysctl_enable_soft_offline) {
pr_info("%#lx: OS-wide disabled\n", pfn);
put_ref_page(pfn, flags);
return -EOPNOTSUPP;
}
We should not be doing anything if soft_offline is disabled, so this check should be placed upfront, at the very beginning of the function. Then you can remove the 'put_ref_page' call.
I think if MF_COUNT_INCREASED is in flags, we still need to put_ref_page(), right?
-- Oscar Salvador SUSE Labs
Add regression and new tests when hugepage has correctable memory errors, and how userspace wants to deal with it: * if enable_soft_offline=1, mapped hugepage is soft offlined * if enable_soft_offline=0, mapped hugepage is intact
Free hugepages case is not explicitly covered by the tests.
Hugepage having corrected memory errors is emulated with MADV_SOFT_OFFLINE.
Signed-off-by: Jiaqi Yan jiaqiyan@google.com --- tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + .../selftests/mm/hugetlb-soft-offline.c | 229 ++++++++++++++++++ tools/testing/selftests/mm/run_vmtests.sh | 4 + 4 files changed, 235 insertions(+) create mode 100644 tools/testing/selftests/mm/hugetlb-soft-offline.c
diff --git a/tools/testing/selftests/mm/.gitignore b/tools/testing/selftests/mm/.gitignore index 0b9ab987601c..064e7b125643 100644 --- a/tools/testing/selftests/mm/.gitignore +++ b/tools/testing/selftests/mm/.gitignore @@ -6,6 +6,7 @@ hugepage-shm hugepage-vmemmap hugetlb-madvise hugetlb-read-hwpoison +hugetlb-soft-offline khugepaged map_hugetlb map_populate diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile index 3b49bc3d0a3b..d166067d75ef 100644 --- a/tools/testing/selftests/mm/Makefile +++ b/tools/testing/selftests/mm/Makefile @@ -42,6 +42,7 @@ TEST_GEN_FILES += gup_test TEST_GEN_FILES += hmm-tests TEST_GEN_FILES += hugetlb-madvise TEST_GEN_FILES += hugetlb-read-hwpoison +TEST_GEN_FILES += hugetlb-soft-offline TEST_GEN_FILES += hugepage-mmap TEST_GEN_FILES += hugepage-mremap TEST_GEN_FILES += hugepage-shm diff --git a/tools/testing/selftests/mm/hugetlb-soft-offline.c b/tools/testing/selftests/mm/hugetlb-soft-offline.c new file mode 100644 index 000000000000..5701eea4ee48 --- /dev/null +++ b/tools/testing/selftests/mm/hugetlb-soft-offline.c @@ -0,0 +1,229 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Test soft offline behavior for HugeTLB pages: + * - if enable_soft_offline = 0, hugepages should stay intact and soft + * offlining failed with EINVAL. + * - if enable_soft_offline = 1, a hugepage should be dissolved and + * nr_hugepages/free_hugepages should be reduced by 1. + * + * Before running, make sure more than 2 hugepages of default_hugepagesz + * are allocated. For example, if /proc/meminfo/Hugepagesize is 2048kB: + * echo 8 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages + */ + +#define _GNU_SOURCE +#include <errno.h> +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include <unistd.h> + +#include <linux/magic.h> +#include <linux/memfd.h> +#include <sys/mman.h> +#include <sys/statfs.h> +#include <sys/types.h> + +#ifndef MADV_SOFT_OFFLINE +#define MADV_SOFT_OFFLINE 101 +#endif + +#define PREFIX " ... " +#define EPREFIX " !!! " + +enum test_status { + TEST_PASS = 0, + TEST_FAILED = 1, + // From ${ksft_skip} in run_vmtests.sh. + TEST_SKIPPED = 4, +}; + +static enum test_status do_soft_offline(int fd, size_t len, int expect_ret) +{ + char *filemap = NULL; + char *hwp_addr = NULL; + const unsigned long pagesize = getpagesize(); + int ret = 0; + enum test_status status = TEST_SKIPPED; + + if (ftruncate(fd, len) < 0) { + perror(EPREFIX "ftruncate to len failed"); + return status; + } + + filemap = mmap(NULL, len, PROT_READ | PROT_WRITE, + MAP_SHARED | MAP_POPULATE, fd, 0); + if (filemap == MAP_FAILED) { + perror(EPREFIX "mmap failed"); + goto untruncate; + } + + memset(filemap, 0xab, len); + printf(PREFIX "Allocated %#lx bytes of hugetlb pages\n", len); + + hwp_addr = filemap + len / 2; + ret = madvise(hwp_addr, pagesize, MADV_SOFT_OFFLINE); + printf(PREFIX "MADV_SOFT_OFFLINE %p ret=%d, errno=%d\n", + hwp_addr, ret, errno); + if (ret != 0) + perror(EPREFIX "madvise failed"); + + if (errno == expect_ret) + status = TEST_PASS; + else { + printf(EPREFIX "MADV_SOFT_OFFLINE should ret %d\n", expect_ret); + status = TEST_FAILED; + } + + munmap(filemap, len); +untruncate: + if (ftruncate(fd, 0) < 0) + perror(EPREFIX "ftruncate back to 0 failed"); + + return status; +} + +static int set_enable_soft_offline(int value) +{ + char cmd[256] = {0}; + FILE *cmdfile = NULL; + + if (value != 0 && value != 1) + return -EINVAL; + + sprintf(cmd, "echo %d > /proc/sys/vm/enable_soft_offline", value); + cmdfile = popen(cmd, "r"); + + if (cmdfile) + printf(PREFIX "enable_soft_offline => %d\n", value); + else { + perror(EPREFIX "failed to set enable_soft_offline"); + return errno; + } + + pclose(cmdfile); + return 0; +} + +static int read_nr_hugepages(unsigned long hugepage_size, + unsigned long *nr_hugepages) +{ + char buffer[256] = {0}; + char cmd[256] = {0}; + + sprintf(cmd, "cat /sys/kernel/mm/hugepages/hugepages-%ldkB/nr_hugepages", + hugepage_size); + FILE *cmdfile = popen(cmd, "r"); + + if (cmdfile == NULL) { + perror(EPREFIX "failed to popen nr_hugepages"); + return -1; + } + + if (!fgets(buffer, sizeof(buffer), cmdfile)) { + perror(EPREFIX "failed to read nr_hugepages"); + pclose(cmdfile); + return -1; + } + + *nr_hugepages = atoll(buffer); + pclose(cmdfile); + return 0; +} + +static int create_hugetlbfs_file(struct statfs *file_stat) +{ + int fd; + + fd = memfd_create("hugetlb_tmp", MFD_HUGETLB); + if (fd < 0) { + perror(EPREFIX "could not open hugetlbfs file"); + return -1; + } + + memset(file_stat, 0, sizeof(*file_stat)); + if (fstatfs(fd, file_stat)) { + perror(EPREFIX "fstatfs failed"); + goto close; + } + if (file_stat->f_type != HUGETLBFS_MAGIC) { + printf(EPREFIX "not hugetlbfs file\n"); + goto close; + } + + return fd; +close: + close(fd); + return -1; +} + +static enum test_status test_soft_offline_common(int enable_soft_offline) +{ + int fd; + int expect_ret = enable_soft_offline ? 0 : EOPNOTSUPP; + struct statfs file_stat; + unsigned long hugepagesize_kb = 0; + unsigned long nr_hugepages_before = 0; + unsigned long nr_hugepages_after = 0; + enum test_status status = TEST_SKIPPED; + + printf("Test soft-offline when enabled_soft_offline=%d\n", + enable_soft_offline); + + fd = create_hugetlbfs_file(&file_stat); + if (fd < 0) { + printf(EPREFIX "Failed to create hugetlbfs file\n"); + return status; + } + + hugepagesize_kb = file_stat.f_bsize / 1024; + printf(PREFIX "Hugepagesize is %ldkB\n", hugepagesize_kb); + + if (set_enable_soft_offline(enable_soft_offline)) + return TEST_FAILED; + + if (read_nr_hugepages(hugepagesize_kb, &nr_hugepages_before) != 0) + return TEST_FAILED; + + printf(PREFIX "Before MADV_SOFT_OFFLINE nr_hugepages=%ld\n", + nr_hugepages_before); + + status = do_soft_offline(fd, 2 * file_stat.f_bsize, expect_ret); + + if (read_nr_hugepages(hugepagesize_kb, &nr_hugepages_after) != 0) + return TEST_FAILED; + + printf(PREFIX "After MADV_SOFT_OFFLINE nr_hugepages=%ld\n", + nr_hugepages_after); + + if (enable_soft_offline) { + if (nr_hugepages_before != nr_hugepages_after + 1) { + printf(EPREFIX "MADV_SOFT_OFFLINE should reduced 1 hugepage\n"); + return TEST_FAILED; + } + } else { + if (nr_hugepages_before != nr_hugepages_after) { + printf(EPREFIX "MADV_SOFT_OFFLINE reduced %lu hugepages\n", + nr_hugepages_before - nr_hugepages_after); + return TEST_FAILED; + } + } + + return status; +} + +int main(void) +{ + enum test_status status; + + status = test_soft_offline_common(1); + if (status != TEST_PASS) + return status; + + status = test_soft_offline_common(0); + if (status != TEST_PASS) + return status; + + printf("Soft-offline tests all good!\n"); + return TEST_PASS; +} diff --git a/tools/testing/selftests/mm/run_vmtests.sh b/tools/testing/selftests/mm/run_vmtests.sh index 3157204b9047..781117fac1ba 100755 --- a/tools/testing/selftests/mm/run_vmtests.sh +++ b/tools/testing/selftests/mm/run_vmtests.sh @@ -331,6 +331,10 @@ CATEGORY="hugetlb" run_test ./thuge-gen CATEGORY="hugetlb" run_test ./charge_reserved_hugetlb.sh -cgroup-v2 CATEGORY="hugetlb" run_test ./hugetlb_reparenting_test.sh -cgroup-v2 if $RUN_DESTRUCTIVE; then +nr_hugepages_tmp=$(cat /proc/sys/vm/nr_hugepages) +echo 8 > /proc/sys/vm/nr_hugepages +CATEGORY="hugetlb" run_test ./hugetlb-soft-offline +echo "$nr_hugepages_tmp" > /proc/sys/vm/nr_hugepages CATEGORY="hugetlb" run_test ./hugetlb-read-hwpoison fi
Add the documentation for soft offline behaviors / costs, and what the new enable_soft_offline sysctl is for.
Signed-off-by: Jiaqi Yan jiaqiyan@google.com --- Documentation/admin-guide/sysctl/vm.rst | 33 +++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index e86c968a7a0e..fc62fc272fc5 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -36,6 +36,7 @@ Currently, these files are in /proc/sys/vm: - dirtytime_expire_seconds - dirty_writeback_centisecs - drop_caches +- enable_soft_offline - extfrag_threshold - highmem_is_dirtyable - hugetlb_shm_group @@ -267,6 +268,38 @@ used:: These are informational only. They do not mean that anything is wrong with your system. To disable them, echo 4 (bit 2) into drop_caches.
+enable_soft_offline +=================== +Correctable memory errors are very common on servers. Soft-offline is kernel's +solution for memory pages having (excessive) corrected memory errors. + +For different types of page, soft-offline has different behaviors / costs. +- For a raw error page, soft-offline migrates the in-use page's content to + a new raw page. +- For a page that is part of a transparent hugepage, soft-offline splits the + transparent hugepage into raw pages, then migrates only the raw error page. + As a result, user is transparently backed by 1 less hugepage, impacting + memory access performance. +- For a page that is part of a HugeTLB hugepage, soft-offline first migrates + the entire HugeTLB hugepage, during which a free hugepage will be consumed + as migration target. Then the original hugepage is dissolved into raw + pages without compensation, reducing the capacity of the HugeTLB pool by 1. + +It is user's call to choose between reliability (staying away from fragile +physical memory) vs performance / capacity implications in transparent and +HugeTLB cases. + +For all architectures, enable_soft_offline controls whether to soft offline +memory pages. When setting to 1, kernel attempts to soft offline the pages +whenever it thinks needed. When setting to 0, kernel returns EOPNOTSUPP to +the request to soft offline the pages. Its default value is 1. + +It is worth mentioning that after setting enable_soft_offline to 0: +- If RAS Correctable Errors Collector is running, its request to soft offline + pages will fail. +- On ARM, the request to soft offline pages from GHES driver will fail. +- On PARISC, the request to soft offline pages from Page Deallocation Table + will fail.
extfrag_threshold =================
On Mon, Jun 17, 2024 at 05:05:45PM +0000, Jiaqi Yan wrote:
Add the documentation for soft offline behaviors / costs, and what the new enable_soft_offline sysctl is for.
Signed-off-by: Jiaqi Yan jiaqiyan@google.com
Documentation/admin-guide/sysctl/vm.rst | 33 +++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index e86c968a7a0e..fc62fc272fc5 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -36,6 +36,7 @@ Currently, these files are in /proc/sys/vm:
- dirtytime_expire_seconds
- dirty_writeback_centisecs
- drop_caches
+- enable_soft_offline
- extfrag_threshold
- highmem_is_dirtyable
- hugetlb_shm_group
@@ -267,6 +268,38 @@ used:: These are informational only. They do not mean that anything is wrong with your system. To disable them, echo 4 (bit 2) into drop_caches. +enable_soft_offline +=================== +Correctable memory errors are very common on servers. Soft-offline is kernel's +solution for memory pages having (excessive) corrected memory errors.
+For different types of page, soft-offline has different behaviors / costs. +- For a raw error page, soft-offline migrates the in-use page's content to
- a new raw page.
+- For a page that is part of a transparent hugepage, soft-offline splits the
- transparent hugepage into raw pages, then migrates only the raw error page.
- As a result, user is transparently backed by 1 less hugepage, impacting
- memory access performance.
+- For a page that is part of a HugeTLB hugepage, soft-offline first migrates
- the entire HugeTLB hugepage, during which a free hugepage will be consumed
- as migration target. Then the original hugepage is dissolved into raw
- pages without compensation, reducing the capacity of the HugeTLB pool by 1.
+It is user's call to choose between reliability (staying away from fragile +physical memory) vs performance / capacity implications in transparent and +HugeTLB cases.
+For all architectures, enable_soft_offline controls whether to soft offline +memory pages. When setting to 1, kernel attempts to soft offline the pages +whenever it thinks needed. When setting to 0, kernel returns EOPNOTSUPP to +the request to soft offline the pages. Its default value is 1.
+It is worth mentioning that after setting enable_soft_offline to 0: +- If RAS Correctable Errors Collector is running, its request to soft offline
- pages will fail.
+- On ARM, the request to soft offline pages from GHES driver will fail. +- On PARISC, the request to soft offline pages from Page Deallocation Table
- will fail.
I do not know about others but the 'fail' word feels wrong here. I would reword that as "... the request to soft offline pages from xxxx will not be performed".
Other than that:
Acked-by: Oscar Salvador osalvador@suse.de
On Tue, Jun 18, 2024 at 10:20 PM Oscar Salvador osalvador@suse.de wrote:
On Mon, Jun 17, 2024 at 05:05:45PM +0000, Jiaqi Yan wrote:
Add the documentation for soft offline behaviors / costs, and what the new enable_soft_offline sysctl is for.
Signed-off-by: Jiaqi Yan jiaqiyan@google.com
Documentation/admin-guide/sysctl/vm.rst | 33 +++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index e86c968a7a0e..fc62fc272fc5 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -36,6 +36,7 @@ Currently, these files are in /proc/sys/vm:
- dirtytime_expire_seconds
- dirty_writeback_centisecs
- drop_caches
+- enable_soft_offline
- extfrag_threshold
- highmem_is_dirtyable
- hugetlb_shm_group
@@ -267,6 +268,38 @@ used:: These are informational only. They do not mean that anything is wrong with your system. To disable them, echo 4 (bit 2) into drop_caches.
+enable_soft_offline +=================== +Correctable memory errors are very common on servers. Soft-offline is kernel's +solution for memory pages having (excessive) corrected memory errors.
+For different types of page, soft-offline has different behaviors / costs. +- For a raw error page, soft-offline migrates the in-use page's content to
- a new raw page.
+- For a page that is part of a transparent hugepage, soft-offline splits the
- transparent hugepage into raw pages, then migrates only the raw error page.
- As a result, user is transparently backed by 1 less hugepage, impacting
- memory access performance.
+- For a page that is part of a HugeTLB hugepage, soft-offline first migrates
- the entire HugeTLB hugepage, during which a free hugepage will be consumed
- as migration target. Then the original hugepage is dissolved into raw
- pages without compensation, reducing the capacity of the HugeTLB pool by 1.
+It is user's call to choose between reliability (staying away from fragile +physical memory) vs performance / capacity implications in transparent and +HugeTLB cases.
+For all architectures, enable_soft_offline controls whether to soft offline +memory pages. When setting to 1, kernel attempts to soft offline the pages +whenever it thinks needed. When setting to 0, kernel returns EOPNOTSUPP to +the request to soft offline the pages. Its default value is 1.
+It is worth mentioning that after setting enable_soft_offline to 0: +- If RAS Correctable Errors Collector is running, its request to soft offline
- pages will fail.
+- On ARM, the request to soft offline pages from GHES driver will fail. +- On PARISC, the request to soft offline pages from Page Deallocation Table
- will fail.
I do not know about others but the 'fail' word feels wrong here. I would reword that as "... the request to soft offline pages from xxxx will not be performed".
Will reword in v4.
Other than that:
Acked-by: Oscar Salvador osalvador@suse.de
Thanks Oscar!
-- Oscar Salvador SUSE Labs
linux-kselftest-mirror@lists.linaro.org