| Message ID | 20240617170545.3820912-2-jiaqiyan@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Userspace controls soft-offline pages | expand |
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: > 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. > 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: > > 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. > > > > 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: >>> 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. >>> >> >> 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 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 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
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 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: > >>> 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. > >>> > >> > >> 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. > . >
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)) {
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(-)