Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-27 Thread Dave Hansen
On 07/26/2016 06:39 PM, hejianet wrote: >>> >> and you choose to patch both of the alloc_*() functions. Why not just >> fix it at the common call site? Seems like that >> spin_lock(_lock) could be a cond_resched_lock() which would fix >> both cases. > I agree to move the cond_resched() to a

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-27 Thread Dave Hansen
On 07/26/2016 06:39 PM, hejianet wrote: >>> >> and you choose to patch both of the alloc_*() functions. Why not just >> fix it at the common call site? Seems like that >> spin_lock(_lock) could be a cond_resched_lock() which would fix >> both cases. > I agree to move the cond_resched() to a

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-26 Thread hejianet
Hi Dave On 7/26/16 11:58 PM, Dave Hansen wrote: On 07/26/2016 08:44 AM, Jia He wrote: This patch is to fix such soft lockup. I thouhgt it is safe to call cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page are out of spin_lock/unlock section. Yikes. So the call site

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-26 Thread hejianet
Hi Dave On 7/26/16 11:58 PM, Dave Hansen wrote: On 07/26/2016 08:44 AM, Jia He wrote: This patch is to fix such soft lockup. I thouhgt it is safe to call cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page are out of spin_lock/unlock section. Yikes. So the call site

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-26 Thread hejianet
On 7/26/16 11:58 PM, Dave Hansen wrote: On 07/26/2016 08:44 AM, Jia He wrote: This patch is to fix such soft lockup. I thouhgt it is safe to call cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page are out of spin_lock/unlock section. Yikes. So the call site for both

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-26 Thread hejianet
On 7/26/16 11:58 PM, Dave Hansen wrote: On 07/26/2016 08:44 AM, Jia He wrote: This patch is to fix such soft lockup. I thouhgt it is safe to call cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page are out of spin_lock/unlock section. Yikes. So the call site for both

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-26 Thread Dave Hansen
On 07/26/2016 08:44 AM, Jia He wrote: > This patch is to fix such soft lockup. I thouhgt it is safe to call > cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page > are out of spin_lock/unlock section. Yikes. So the call site for both the things you patch is this: >

Re: [RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-26 Thread Dave Hansen
On 07/26/2016 08:44 AM, Jia He wrote: > This patch is to fix such soft lockup. I thouhgt it is safe to call > cond_resched() because alloc_fresh_gigantic_page and alloc_fresh_huge_page > are out of spin_lock/unlock section. Yikes. So the call site for both the things you patch is this: >

[RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-26 Thread Jia He
In large memory(32TB) powerpc servers, we watched several soft lockup under stress tests. The call trace are as follows: 1. get_page_from_freelist+0x2d8/0xd50 __alloc_pages_nodemask+0x180/0xc20 alloc_fresh_huge_page+0xb0/0x190 set_max_huge_pages+0x164/0x3b0 2.

[RFC PATCH] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()

2016-07-26 Thread Jia He
In large memory(32TB) powerpc servers, we watched several soft lockup under stress tests. The call trace are as follows: 1. get_page_from_freelist+0x2d8/0xd50 __alloc_pages_nodemask+0x180/0xc20 alloc_fresh_huge_page+0xb0/0x190 set_max_huge_pages+0x164/0x3b0 2.