Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7936366pxb; Fri, 19 Feb 2021 03:18:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJxbFlS795/c7sg7Tstwl6lzCZV9vBxqT6uuLuTf/Bgv+lqpL0kZXwZ/srrErFWOldejUyqi X-Received: by 2002:a17:906:6095:: with SMTP id t21mr8300898ejj.384.1613733529188; Fri, 19 Feb 2021 03:18:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613733529; cv=none; d=google.com; s=arc-20160816; b=cWGFocqbDsjIlQxY92pPDn0WDgohYrqp1jPUVWZCRoFE7WbLVIkBNjk9HKaTkLmwDq 5CkyUQVU6Kqd/I2OEz982kGQ+PEYIXVd2dWBHKOgFerReRlqo2d505VqhqqiVJ6QfVf8 CR5eU0gkbUInwx47hHlkyQFMqrDZn3mzri9eU/Z5LKcDg12wBEfUKmPszc8gaHFggr9V WALtrgA5RnLKWxjqCI0BKdiV3awf9deq3M3GlAYMGuFbrFmnPJBIqMtuSWnCWJS26jZv 6Mqyl6EgnksvyA+XjCGSLxBnXEi3yn9yHsA/o7b9RWXw6v31G+NVIBl4outlNn+UYoes yAQA== 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=fNem62r/Qze7L7YZM+orIsqwyTjXnafd6inPW4d0TYo=; b=llkITg4llwWNXcr5d5Ln9D+4DnjIDz4pD357kmvD+vOtQHKLCtUgBcnpkk/pJ1gb8U jJ5j6sB1SCWRKjms5AspsCzV7Et4Hs3PLSw1IUhG23bk9nr6K1wpax0P4FMAto3LzVgk vvepcz3/CpTp4vgmceoSnprPlvhearLsZ1QQd1Mn7tyICko/lg+2B/LFLpQwWvDUoVhX spEJ2PERcyk/1DPfAYMHNMHjGgIBh4EgCwDEo7h2cKOal4YFUmRs84skOi8xHXd5RXpV ZulULTSLGFMeN+FaYod0lcJ5r7Q+B2A+sL3VS95MUSqhQ9Xg+TL4a1mYOaVcwpZdfafX a5xA== 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 z102si5627958ede.224.2021.02.19.03.18.24; Fri, 19 Feb 2021 03:18: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 S229878AbhBSLRz (ORCPT + 99 others); Fri, 19 Feb 2021 06:17:55 -0500 Received: from mx2.suse.de ([195.135.220.15]:36512 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229678AbhBSLRy (ORCPT ); Fri, 19 Feb 2021 06:17:54 -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 7CDC7AC6E; Fri, 19 Feb 2021 11:17:13 +0000 (UTC) Date: Fri, 19 Feb 2021 12:17:11 +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: <20210219111703.GA20286@linux> References: <20210217100816.28860-2-osalvador@suse.de> <20210218100917.GA4842@localhost.localdomain> <20210218133250.GA7983@localhost.localdomain> <20210219090548.GA17266@linux> <20210219103943.GA19945@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 11:55:00AM +0100, Michal Hocko wrote: > It is not the lock that I care about but more about counters. The > intention was that there is a single place to handle both enqueing and > dequeing. As not all places require counters to be updated. E.g. the > migration which just replaces one page by another. I see. alloc_fresh_huge_page->prep_new_huge_page increments h->nr_huge_pages{_node} counters. Which means: > 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); Here we need update_and_free_page, otherwise we would be leaving a stale value in h->nr_huge_pages{_node}. > goto unlock; > } > list_del(&old_page->lru); > __update_and_free_page(old_page); Same here. > __enqueue_huge_page(new_page); This is ok since h->free_huge_pages{_node} do not need to be updated. -- Oscar Salvador SUSE L3