Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7792852pxb; Thu, 18 Feb 2021 22:10:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJzjOjdE0kcRNw3VZ78taqyT2PSOFU7WSYEpw3wGUWZUqLfpG0p19KQiLF3siw2TGtvjIJMe X-Received: by 2002:a17:906:ccd8:: with SMTP id ot24mr7544594ejb.46.1613715047869; Thu, 18 Feb 2021 22:10:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613715047; cv=none; d=google.com; s=arc-20160816; b=ZIN5/vfl2t1lxd+CgDGLNIyoy9WTQsDECtjq2/gu3nr3dBCDxuo4JUccuVrilPfY+B WzxJSzZlrYNW+nYaARx4LWZVNaZ8l6UAbdcyem0D7ZcgxcUpTXiD+r3Q1HuXPRfkih+N jNHslAKaemsP6z2WBq9Mg1gpsU72ZaQQZfE9le7YsxXml0FzE30+1vuCB7VHtaoWCXSG gYR0u96sBKtOi5xs1ucaMQc0AdUC77cDqBxpmp88z3vc+ltD8Kr/QX//9HFoHutIMZqJ TsXvlikFPy9Mu7l/tcfcfeRxWl3G9gkU0hUZzksTsFwcqMRxxOOyghpoy86JDfnMIWFX wv/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:user-agent :references:in-reply-to:subject:cc:to:from:date:mime-version; bh=J3p6SUS+C3WZkHmz6HGHnfH351xMV7GI7gDx6iKssqs=; b=XlEgL6FF1ad7KIJ8aN7EQkXvM2kzjQ1+g341bjPIIhZyH6pi01B6OVAOfSqaZJdXuj GBc/YzTAYe9YP+eBYFAmW4Z4/rfBPd8ZbKe3+d4xgbKRBL81AwsROuWsaANvm/decaum O9SkFvBKMeyYLpa0SAkImwujc+xf67aLXNGLfQtDd3nsBtQZENXnSxZ15hxC5tQe4h9S aJpx2jB01Ubuajek5inj2BZsVQxhPBI0iNwr8/BQGR7U/2LLvWZgkTXUCE/KhaGWJPh4 JB1+sNqK0mxtL8GthCR2dIGt95tU6df5KHLny+fH5v6rwKd3CH3cLrnq7N1CgYMMwawT 1BoQ== 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 hs7si6339696ejc.745.2021.02.18.22.10.25; Thu, 18 Feb 2021 22:10:47 -0800 (PST) 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 S229809AbhBSGJP (ORCPT + 99 others); Fri, 19 Feb 2021 01:09:15 -0500 Received: from mx2.suse.de ([195.135.220.15]:45620 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229544AbhBSGIx (ORCPT ); Fri, 19 Feb 2021 01:08:53 -0500 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 87039AC69; Fri, 19 Feb 2021 06:08:07 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 19 Feb 2021 07:08:06 +0100 From: Oscar Salvador To: Mike Kravetz Cc: Andrew Morton , David Hildenbrand , Michal Hocko , Muchun Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm: Make alloc_contig_range handle free hugetlb pages In-Reply-To: <9a902aae-7478-4287-ad5c-f6b0b7fdf2ad@oracle.com> References: <20210218120028.6499-1-osalvador@suse.de> <20210218120028.6499-2-osalvador@suse.de> <9a902aae-7478-4287-ad5c-f6b0b7fdf2ad@oracle.com> User-Agent: Roundcube Webmail Message-ID: <73df96ab131fb1587c3527a5ca151c08@suse.de> X-Sender: osalvador@suse.de Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-02-19 03:10, Mike Kravetz wrote: > Those counts will be wrong as there are no huge pages on the node. > > I'll think about this more tomorrow. > Pretty sure this is an issue, but I could be wrong. Just wanted to > give > a heads up. Yes, this is a problem, although the fixup would be to check whether we have any hugepages. Nevertheless, I think we should not be touching surplus at all but rather make the page temporary. I am exploring making migrate_pages() handle free hugepages as Michal suggested, so the approach is cleaner and we do not need extra functions. I yet have to see if that is feasible, as some issues come to my mind like the page needs to be in a list to go to migrate_pages, but if it is in that list, it is not in hugepages_freelist, and that could disrupt userspace as it could not dequeue hugepages if it demands it. I have to check. Shoult not be possible, we can always make the page temporary here. > -- > Mike Kravetz > >> + } >> + } >> + >> + return ret; >> +} >> + >> +bool isolate_or_dissolve_huge_page(struct page *page) >> +{ >> + struct hstate *h = NULL; >> + struct page *head; >> + bool ret = false; >> + >> + spin_lock(&hugetlb_lock); >> + if (PageHuge(page)) { >> + head = compound_head(page); >> + h = page_hstate(head); >> + } >> + spin_unlock(&hugetlb_lock); >> + >> + /* >> + * The page might have been dissolved from under our feet. >> + * If that is the case, return success as if we dissolved it >> ourselves. >> + */ >> + if (!h) >> + return true; >> + >> + /* >> + * Fence off gigantic pages as there is a cyclic dependency >> + * between alloc_contig_range and them. >> + */ >> + if (hstate_is_gigantic(h)) >> + return ret; >> + >> + if(!page_count(head) && alloc_and_dissolve_huge_page(h, head)) >> + ret = true; >> + >> + return ret; >> +} >> + >> struct page *alloc_huge_page(struct vm_area_struct *vma, >> unsigned long addr, int avoid_reserve) >> { >> -- Oscar Salvador SUSE L3