[PATCH] mm, hwpoison: Add comment describing when to add new cases

[PATCH] mm, hwpoison: Add comment describing when to add new cases

[Andi Kleen]

From: Andi Kleen <ak@linux.intel.com>

Here's another comment fix for hwpoison.

It describes the "guiding principle" on when to add new
memory error recovery code.

v2: Add URL
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 mm/memory-failure.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 25c2054..97e44d3 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -20,6 +20,14 @@
  * this code has to be extremely careful. Generally it tries to use 
  * normal locking rules, as in get the standard locks, even if that means 
  * the error handling takes potentially a long time.
+ *
+ * It can be very tempting to add handling for obscure cases here.
+ * In general any code for handling new cases should only be added iff:
+ * - You know how to test it.
+ * - You have a test that can be added to mce-test
+ *   https://git.kernel.org/cgit/utils/cpu/mce/mce-test.git/
+ * - The case actually shows up as a frequent (top 10) page state in
+ *   tools/vm/page-types when running a real workload.
  * 
  * There are several operations here with exponential complexity because
  * of unsuitable VM data structures. For example the operation to map back 
-- 
1.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH] mm, hwpoison: Add comment describing when to add new cases

[Andi Kleen]

From: Andi Kleen <ak@linux.intel.com>

Here's another comment fix for hwpoison.

It describes the "guiding principle" on when to add new
memory error recovery code.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 mm/memory-failure.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 25c2054..d553993 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -20,6 +20,13 @@
  * this code has to be extremely careful. Generally it tries to use 
  * normal locking rules, as in get the standard locks, even if that means 
  * the error handling takes potentially a long time.
+ *
+ * It can be very tempting to add handling for obscure cases here.
+ * In general any code for handling new cases should only be added if:
+ * - You know how to test it.
+ * - You have a test that can be added to mce-test
+ * - The case actually shows up as a frequent (top 10) page state in
+ *   tools/vm/page-types when running a real workload.
  * 
  * There are several operations here with exponential complexity because
  * of unsuitable VM data structures. For example the operation to map back 
-- 
1.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, hwpoison: Add comment describing when to add new cases

[Andrew Morton]

On Tue, 21 Apr 2015 11:11:30 -0700 Andi Kleen <andi@firstfloor.org> wrote:

> From: Andi Kleen <ak@linux.intel.com>
> 
> Here's another comment fix for hwpoison.
> 
> It describes the "guiding principle" on when to add new
> memory error recovery code.
> 
> Signed-off-by: Andi Kleen <ak@linux.intel.com>
> ---
>  mm/memory-failure.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 25c2054..d553993 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -20,6 +20,13 @@
>   * this code has to be extremely careful. Generally it tries to use 
>   * normal locking rules, as in get the standard locks, even if that means 
>   * the error handling takes potentially a long time.
> + *
> + * It can be very tempting to add handling for obscure cases here.
> + * In general any code for handling new cases should only be added if:
> + * - You know how to test it.
> + * - You have a test that can be added to mce-test

Some additional details on mce-test might be useful.  The goog leads me
to https://github.com/andikleen/mce-test but that hasn't been touched
in 3 years?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, hwpoison: Add comment describing when to add new cases

[Andi Kleen]

> > + *
> > + * It can be very tempting to add handling for obscure cases here.
> > + * In general any code for handling new cases should only be added if:
> > + * - You know how to test it.
> > + * - You have a test that can be added to mce-test
> 
> Some additional details on mce-test might be useful.  The goog leads me
> to https://github.com/andikleen/mce-test but that hasn't been touched
> in 3 years?

The latest version is here https://git.kernel.org/cgit/utils/cpu/mce/mce-test.git/

Will send a new patch.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm, hwpoison: Add comment describing when to add new cases

[Naoya Horiguchi]

On Tue, Apr 21, 2015 at 11:11:30AM -0700, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 
> Here's another comment fix for hwpoison.
> 
> It describes the "guiding principle" on when to add new
> memory error recovery code.
> 
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>

> ---
>  mm/memory-failure.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 25c2054..d553993 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -20,6 +20,13 @@
>   * this code has to be extremely careful. Generally it tries to use 
>   * normal locking rules, as in get the standard locks, even if that means 
>   * the error handling takes potentially a long time.
> + *
> + * It can be very tempting to add handling for obscure cases here.
> + * In general any code for handling new cases should only be added if:
> + * - You know how to test it.
> + * - You have a test that can be added to mce-test
> + * - The case actually shows up as a frequent (top 10) page state in
> + *   tools/vm/page-types when running a real workload.
>   * 
>   * There are several operations here with exponential complexity because
>   * of unsuitable VM data structures. For example the operation to map back 
> -- 
> 1.9.3
> 
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>