Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7916874pxb; Fri, 19 Feb 2021 02:44:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJw+CMHK47S2u9Ue9cEyXo0Pf0avzwJRejuCBWVO7lftyp+oSatC2NV6bHJG6M17BFOaI0yd X-Received: by 2002:a17:906:7d87:: with SMTP id v7mr4755558ejo.214.1613731489076; Fri, 19 Feb 2021 02:44:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613731489; cv=none; d=google.com; s=arc-20160816; b=fNCH5PXVi/hTmQCYD6+Jw+JZBOsMBs46vBYy+nBXAZdmbKDM1NRCA0Ryzuyg9LLLY3 vyn5KzJxvDSYDe9TQ6NAr7G4BM/ucf68GFZ25XwACxwpjPEB8GEBqhSwQr9JOqcZwYZw y6H0xLVxjiR419/k5yD5aYEZyysoxCEU5tYuhdb19vfzIQVPQer4intMY0VRApOvNbhT diyM0R6gPADHW9g+kyj+MP+AuEBD41N3gRqLEYVrUrNaIlGpL8EMvy3bdc44suaPx3Bd 685lGg5LY1WnO6X1CF6pgqH1s+nuDv0BqF3qrEHDPbocvexuvQSHMCuBJ4Gi9uAKMFO4 Whhw== 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=EFOq/p+9SD6ouZoIZZwGf9rJIqWHxOdVugm66pKZMaU=; b=n361zA5yKs1JTWi8uUVvc6BCAok+OuGHWQw00RuSnPnwm7UKtsVi72fUEx794FK/Jq t3MWRrLJUzaK4aU+3LhdIxyWTNN3h3Nmj3xSE3sGbXUGGa9ECTpYl2IdkiuEsUVD35fJ z87NeO9Aad0wyOnOShVDX3yBmXXE9HjHiYLszocNILdmIooDVv9jnROLMeFyQIFE2GQP ue4oUL35MiXsApKV/Gv6dCfopK5ZyFby7dyw+wAeMIh9o3dOrrRmPavIvnMy2b4OhZPM 5c4a1x12ILGXl1H3sjOwG25B/Y1NGG2VGG5mLavLrSf5tmW5c1sdDxxtHT9JiY8Fx26M FV6Q== 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 a11si274704ejt.753.2021.02.19.02.44.25; Fri, 19 Feb 2021 02:44:49 -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 S229527AbhBSKlR (ORCPT + 99 others); Fri, 19 Feb 2021 05:41:17 -0500 Received: from mx2.suse.de ([195.135.220.15]:42242 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229998AbhBSKlN (ORCPT ); Fri, 19 Feb 2021 05:41:13 -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 7D483AC6E; Fri, 19 Feb 2021 10:40:32 +0000 (UTC) Date: Fri, 19 Feb 2021 11:40:30 +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: <20210219103943.GA19945@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. On a closer look, do we really need to decouple update_and_free_page and enqueue_huge_page? These two functions do not handle the lock, but rather the functions that call them (as would be in our case). Only update_and_free_page drops the lock during the freeing of a gigantic page and then it takes it again, as the caller is who took the lock. am I missing anything obvious here? -- Oscar Salvador SUSE L3