On 07/12/23 11:14, Mike Kravetz wrote:
On 07/12/23 16:03, Muchun Song wrote:
On Jul 12, 2023, at 06:09, Mike Kravetz mike.kravetz@oracle.com wrote:
Note that this will leave hugetlb pages in a state where they are marked free (by hugetlb specific page flag) and have a ref count. This is not a normal state. The only code that would notice is the memory error code, and it is set up to retry in such a case.
A subsequent patch will create a routine to do bulk processing of vmemmap allocation. This will eliminate a lock/unlock cycle for each hugetlb page in the case where we are freeing a large number of pages.
Fixes: ad2fa3717b74 ("mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page") Cc: stable@vger.kernel.org Signed-off-by: Mike Kravetz mike.kravetz@oracle.com
Hi Mike,
I have seen an issue proposed by Jiaqi Yan in [1]. I didn't see any resolution for it. Am I missing something with this fix?
[1] https://lore.kernel.org/linux-mm/CACw3F53iPiLrJt4pyaX2aaZ5BVg9tj8x_k6-v7=9Xn...
My mistake! I sent the old version of the patch.
The new version was modified to simply check the destructor via folio_test_hugetlb() in order to decide if it should be cleared.
I will send V2. Sorry!
I was about to send v2 when I noticed that this approach opened another race window. :( Closing the window should be just a matter of reordering code. I will take a day or two to make sure I did not miss something else.