From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965958AbcIVTOp (ORCPT ); Thu, 22 Sep 2016 15:14:45 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:41067 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936317AbcIVTOf (ORCPT ); Thu, 22 Sep 2016 15:14:35 -0400 Subject: Re: [PATCH v3] mm/hugetlb: fix memory offline with hugepage size > memory block size To: Dave Hansen , Gerald Schaefer , Andrew Morton References: <20160920155354.54403-1-gerald.schaefer@de.ibm.com> <20160920155354.54403-2-gerald.schaefer@de.ibm.com> <05d701d213d1$7fb70880$7f251980$@alibaba-inc.com> <20160921143534.0dd95fe7@thinkpad> <20160922095137.GC11875@dhcp22.suse.cz> <20160922154549.483ee313@thinkpad> <20160922182937.38af9d0e@thinkpad> <57E41EF6.1010903@linux.intel.com> Cc: Michal Hocko , Naoya Horiguchi , Hillf Danton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A . Shutemov" , Vlastimil Babka , "Aneesh Kumar K . V" , Martin Schwidefsky , Heiko Carstens , Rui Teng From: Mike Kravetz Message-ID: Date: Thu, 22 Sep 2016 12:13:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <57E41EF6.1010903@linux.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/22/2016 11:12 AM, Dave Hansen wrote: > On 09/22/2016 09:29 AM, Gerald Schaefer wrote: >> static void dissolve_free_huge_page(struct page *page) >> { >> + struct page *head = compound_head(page); >> + struct hstate *h = page_hstate(head); >> + int nid = page_to_nid(head); >> + >> spin_lock(&hugetlb_lock); >> - if (PageHuge(page) && !page_count(page)) { >> - struct hstate *h = page_hstate(page); >> - int nid = page_to_nid(page); >> - list_del(&page->lru); >> - h->free_huge_pages--; >> - h->free_huge_pages_node[nid]--; >> - h->max_huge_pages--; >> - update_and_free_page(h, page); >> - } >> + list_del(&head->lru); >> + h->free_huge_pages--; >> + h->free_huge_pages_node[nid]--; >> + h->max_huge_pages--; >> + update_and_free_page(h, head); >> spin_unlock(&hugetlb_lock); >> } > > Do you need to revalidate anything once you acquire the lock? Can this, > for instance, race with another thread doing vm.nr_hugepages=0? Or a > thread faulting in and allocating the large page that's being dissolved? I originally suggested the locking change, but this is not quite right. The page count for huge pages is adjusted while holding hugetlb_lock. So, that check or a revalidation needs to be done while holding the lock. That question made me think about huge page reservations. I don't think the offline code takes this into account. But, you would not want your huge page count to drop below the reserved huge page count (resv_huge_pages). So, shouldn't this be another condition to check before allowing the huge page to be dissolved? -- Mike Kravetz