Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7903658pxb; Fri, 19 Feb 2021 02:19:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJzCPz6RiSXnEJUkbmbnftE6EzZFKwqJM5XEb2gSIiKPE8595s1xpyhsQq7IPrbXl0t5EXuW X-Received: by 2002:aa7:d617:: with SMTP id c23mr8334161edr.215.1613729958802; Fri, 19 Feb 2021 02:19:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613729958; cv=none; d=google.com; s=arc-20160816; b=sduoIGATTuvbcqlwFEwlNiyFDU1yS6vGHBrfWBYPisdqTcMYx9QI0jpOyKK3fL+XzD LYTbSBacKDjBGu39tmiYVpWXuFQtTiyJIONbd6piTiQIPq+mxO9k/pPIKR/5XV9y3wAs HtUPizs58yPdb6DpIM9zu255b5rPtegM6I5+xv1nxI26ya6JDVF0AajMiu7FhoPKuelo 8kdmcxj8VjH+4rZ3zCG9qcaXesdbpKh8dS1jpWa9Mzi61uqm0950FJ+6chhcsTQWxUJ+ zVSfIuTmz4IZ5jkJIgmRAS2SvCsNn3KJdv7Z+9AKDTgjm3W3P+uNPl8cgbiiPbZfNemT Dv3w== 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=S2WfikJUeA0vhZhlAzVXBfLO3ZUY32f5QziX05jUr8Y=; b=nNOVW5eq4oLPCHoGOitIjT9X0XYQZZZcRhOSPWXCR9d0UAVRvrUNMpOyyoVD80fXpD sWz85XwLmfWrC/9PrrYMQeuu/foiDqbzyPkS8ck7yvjXJE94Uam27dlti1JU/zqFpDZI 9aoXotl/hcefuBRJ4htV9yVb8YwTLDbSCHPWwiwDt1RasESXNd3CKbPxQ1Dxb/SYFNm9 u+2rCGuSObgyavx5r/OkWPm5tfTscCKqrHJN8KOEP9/zNU0cP0XrSPF0MwC3prhkgrz3 JoeJjuIn1jGjbcOkFql4W42sOstHcMXm0nyRuuDERo2D8dL2A0gpgnwaU7aR7nzDEE7c iVDw== 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 le28si1909594ejc.175.2021.02.19.02.18.55; Fri, 19 Feb 2021 02:19:18 -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 S230417AbhBSKQ1 (ORCPT + 99 others); Fri, 19 Feb 2021 05:16:27 -0500 Received: from mx2.suse.de ([195.135.220.15]:55640 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230380AbhBSKPQ (ORCPT ); Fri, 19 Feb 2021 05:15:16 -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 D735FACCF; Fri, 19 Feb 2021 10:14:34 +0000 (UTC) Date: Fri, 19 Feb 2021 11:14:32 +0100 From: Oscar Salvador To: Michal Hocko Cc: Andrew Morton , Mike Kravetz , David Hildenbrand , Muchun Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages Message-ID: <20210219101427.GA19588@linux> References: <20210217100816.28860-1-osalvador@suse.de> <20210217100816.28860-2-osalvador@suse.de> <20210218100917.GA4842@localhost.localdomain> <20210218133250.GA7983@localhost.localdomain> <20210219090548.GA17266@linux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 19, 2021 at 10:56:42AM +0100, Michal Hocko wrote: > OK, this should work but I am really wondering whether it wouldn't be > just simpler to replace the old page by a new one in the free list > directly. Or is there any reason we have to go through the generic > helpers path? I mean something like this > > new_page = alloc_fresh_huge_page(); > if (!new_page) > goto fail; > spin_lock(hugetlb_lock); > if (!PageHuge(old_page)) { > /* freed from under us, nothing to do */ > __update_and_free_page(new_page); > goto unlock; > } > list_del(&old_page->lru); > __update_and_free_page(old_page); > __enqueue_huge_page(new_page); > unlock: > spin_unlock(hugetlb_lock); > > This will require to split update_and_free_page and enqueue_huge_page to > counters independent parts but that shouldn't be a big deal. But it will > also protect from any races. Not an act of beauty but seems less hackish > to me. Yes, I think this would to the trick, and it is race-free. Let me play with it a bit and see what I can come up with. Thanks for the valuable insight. -- Oscar Salvador SUSE L3