Re: [PATCH 2/4] mm/hwpoison: fix miss catch transparent huge page
On Mon, Sep 02, 2013 at 08:33:42PM +0800, Wanpeng Li wrote:
> PageTransHuge() can't guarantee the page is transparent huge page since it
> return true for both transparent huge and hugetlbfs pages. This patch fix
> it by check the page is also !hugetlbfs page.
>
> Before patch:
>
> [ 121.571128] Injecting memory failure at pfn 23a200
> [ 121.571141] MCE 0x23a200: huge page recovery: Delayed
> [ 140.355100] MCE: Memory failure is now running on 0x23a200
>
> After patch:
>
> [ 94.290793] Injecting memory failure at pfn 23a000
> [ 94.290800] MCE 0x23a000: huge page recovery: Delayed
> [ 105.722303] MCE: Software-unpoisoned page 0x23a000
>
> Signed-off-by: Wanpeng Li
PageTransHuge doesn't care about hugetlbfs at all, assuming that it
shouldn't be called hugetlbfs context as commented.
/*
* PageHuge() only returns true for hugetlbfs pages, but not for
* normal or transparent huge pages.
*
* PageTransHuge() returns true for both transparent huge and
* hugetlbfs pages, but not normal pages. PageTransHuge() can only be
* called only in the core VM paths where hugetlbfs pages can't exist.
*/
static inline int PageTransHuge(struct page *page)
I think it's for the ultra optimization of thp, so we can't change that.
So we need to follow the pattern whenever possible.
if (PageHuge) {
hugetlb specific code
} else if (PageTransHuge) {
thp specific code
}
normal page code / common code
> ---
> mm/memory-failure.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index e28ee77..b114570 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
>* worked by memory_failure() and the page lock is not held yet.
>* In such case, we yield to memory_failure() and make unpoison fail.
>*/
> - if (PageTransHuge(page)) {
> + if (PageTransHuge(page) && !PageHuge(page)) {
> pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
> return 0;
> }
I think that we can effectively follow the above pattern by reversing
these two checks.
Thanks,
Naoya Horiguchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] mm/hwpoison: fix miss catch transparent huge page
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (PageTransHuge(page) && !PageHuge(page)) {
pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] mm/hwpoison: fix miss catch transparent huge page
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (PageTransHuge(page) !PageHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] mm/hwpoison: fix miss catch transparent huge page
On Mon, Sep 02, 2013 at 08:33:42PM +0800, Wanpeng Li wrote:
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
PageTransHuge doesn't care about hugetlbfs at all, assuming that it
shouldn't be called hugetlbfs context as commented.
/*
* PageHuge() only returns true for hugetlbfs pages, but not for
* normal or transparent huge pages.
*
* PageTransHuge() returns true for both transparent huge and
* hugetlbfs pages, but not normal pages. PageTransHuge() can only be
* called only in the core VM paths where hugetlbfs pages can't exist.
*/
static inline int PageTransHuge(struct page *page)
I think it's for the ultra optimization of thp, so we can't change that.
So we need to follow the pattern whenever possible.
if (PageHuge) {
hugetlb specific code
} else if (PageTransHuge) {
thp specific code
}
normal page code / common code
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (PageTransHuge(page) !PageHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
I think that we can effectively follow the above pattern by reversing
these two checks.
Thanks,
Naoya Horiguchi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
