Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp867077pxf; Wed, 7 Apr 2021 13:41:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwsTawHQHq7MnmZeNrkrOcs3I/SRfncTh8FUqqSRnst6+e7e55Z1PXTWsbGTIfuwdZwac6T X-Received: by 2002:a17:906:565a:: with SMTP id v26mr6055978ejr.516.1617828070428; Wed, 07 Apr 2021 13:41:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617828070; cv=none; d=google.com; s=arc-20160816; b=nva/hZCL1Jq8jjXQ6WJ4M/I4MUFfk//Yh8REbcDDi9v+qJYKhnbc/PNb0A199191Ns /XNjvrVe7EIH13TXruVInTKjEXNHGukosKNBP6wd78iadjPqRs7u9KfhUCp7fONWHZR3 GaKIIhPt9OgmmJqcRWbMEQ7S2P1KoL1BqAiwi0Pg0r/uEvT/SkUMCtocr0w/q6qbAgK+ o8r/f3G/H95oL9amxCsCFKz24lKAwfh+1TszBz9OzXERyq61i1ZrB2mbz7XRzXW3KhQy rs+e0uTU4Fz1f0o5j7Nyh+0E5QvzTxckiRnzYWhxw5qsLaR9+c1+06c+iLITo9Hnv2Ee inZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=AGb60pDMfY+9aBQyfortG9S9xt9fhZVmJ2ybtUc1HfA=; b=NKlch7ETFW5+5Zp2dDsktXwWLqTi88yFG9ODw+NdD5XTUchPJ9LEMaITzIiU0syoRp iomq4Z17jAXToh2qlwYy6Fpuu8JvVaYbABSnzgO7e1JCmB1WRVK97Ac3VALq3TpF6bgA /tWBcx5srk7UsutK1EvIiHxKsLCVLtm4yjGlMklAvacUf401i308kdQMjyNOh83y9LqK GUyEVBTiLdlW552zmeoODu5jgRaobiDB0qWtAhgZ8glB7MUAuiS6rWm+dYHC3X6X4SUR aV6i0/5j0WQuAzRIt+VvHslk8pKNAo1wx0+aq8YfJqGDPgUaWh08ImOfWTeh7BF1HRhw 7ktA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dj16si6860522edb.368.2021.04.07.13.40.47; Wed, 07 Apr 2021 13:41:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349887AbhDGJDt (ORCPT + 99 others); Wed, 7 Apr 2021 05:03:49 -0400 Received: from mx2.suse.de ([195.135.220.15]:47560 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239586AbhDGJDt (ORCPT ); Wed, 7 Apr 2021 05:03:49 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D3E30AFC1; Wed, 7 Apr 2021 08:44:42 +0000 (UTC) Date: Wed, 7 Apr 2021 10:44:38 +0200 From: Oscar Salvador To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Roman Gushchin , Michal Hocko , Shakeel Butt , David Hildenbrand , Muchun Song , David Rientjes , Miaohe Lin , Peter Zijlstra , Matthew Wilcox , HORIGUCHI NAOYA , "Aneesh Kumar K . V" , Waiman Long , Peter Xu , Mina Almasry , Hillf Danton , Joonsoo Kim , Barry Song , Will Deacon , Andrew Morton Subject: Re: [PATCH v4 6/8] hugetlb: change free_pool_huge_page to remove_pool_huge_page Message-ID: <20210407084438.GB10058@linux> References: <20210405230043.182734-1-mike.kravetz@oracle.com> <20210405230043.182734-7-mike.kravetz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210405230043.182734-7-mike.kravetz@oracle.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 05, 2021 at 04:00:41PM -0700, Mike Kravetz wrote: > free_pool_huge_page was called with hugetlb_lock held. It would remove > a hugetlb page, and then free the corresponding pages to the lower level > allocators such as buddy. free_pool_huge_page was called in a loop to > remove hugetlb pages and these loops could hold the hugetlb_lock for a > considerable time. > > Create new routine remove_pool_huge_page to replace free_pool_huge_page. > remove_pool_huge_page will remove the hugetlb page, and it must be > called with the hugetlb_lock held. It will return the removed page and > it is the responsibility of the caller to free the page to the lower > level allocators. The hugetlb_lock is dropped before freeing to these > allocators which results in shorter lock hold times. > > Add new helper routine to call update_and_free_page for a list of pages. > > Note: Some changes to the routine return_unused_surplus_pages are in > need of explanation. Commit e5bbc8a6c992 ("mm/hugetlb.c: fix reservation > race when freeing surplus pages") modified this routine to address a > race which could occur when dropping the hugetlb_lock in the loop that > removes pool pages. Accounting changes introduced in that commit were > subtle and took some thought to understand. This commit removes the > cond_resched_lock() and the potential race. Therefore, remove the > subtle code and restore the more straight forward accounting effectively > reverting the commit. > > Signed-off-by: Mike Kravetz > Reviewed-by: Muchun Song > Acked-by: Michal Hocko Reviewed-by: Oscar Salvador It crossed my mind that we could use update_and_free_pages_bulk() from dissolve_free_huge_pages() <-> dissolve_free_huge_page() but the latter looks too hairy already and it is probably not worth it. -- Oscar Salvador SUSE L3