From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE801ECAAD5 for ; Mon, 5 Sep 2022 20:07:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC832801FF; Mon, 5 Sep 2022 16:07:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E7851801E6; Mon, 5 Sep 2022 16:07:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3F79801FF; Mon, 5 Sep 2022 16:07:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C2811801E6 for ; Mon, 5 Sep 2022 16:07:32 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 96A311408DF for ; Mon, 5 Sep 2022 20:07:32 +0000 (UTC) X-FDA: 79879116744.29.97698C3 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf12.hostedemail.com (Postfix) with ESMTP id 31D084007D for ; Mon, 5 Sep 2022 20:07:32 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 80383B81112; Mon, 5 Sep 2022 20:07:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D5BEC433D6; Mon, 5 Sep 2022 20:07:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1662408449; bh=ysM9awpw0A2M34q5JF3n3+0RW+KGU1zgTfvVfudH32Y=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oecxaYBa382HbPtWr3k1hVeYfFE3D4Ang+wYKMylmV+PLsjYj5BzbU7EvmMU4rVg6 PvuoEB5byW/91Ca1yoXE1cSyPQHCKUKSSeMoT5aF+Z1JIAvR5W3C53Vy422ZjIDm8g eB1YPrhQWOFcCtyKaGWaHt9BWFb6X2n6qA660nwQ= Date: Mon, 5 Sep 2022 13:07:28 -0700 From: Andrew Morton To: Liu Shixin Cc: , , Kefeng Wang Subject: Re: [PATCH] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice Message-Id: <20220905130728.1e814d185b189faece6f2c2f@linux-foundation.org> In-Reply-To: <20220905133813.2253703-1-liushixin2@huawei.com> References: <20220905133813.2253703-1-liushixin2@huawei.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662408452; a=rsa-sha256; cv=none; b=zqIDIedkBtv8mIdime+YPXak/3JjeLJ+8cJUbd0Gsfx8t+bBHSXpaoPiqTqb0Xq0V85KFh kJBJG29xRDo7M3Cacyb0A0E5cGGMhgiecmY/Rqp6xWHJmSkNNieFHkolgwF1dCmPjjvMFP tznqWZUWi+kFFopOXES+BN7MHPHWoRA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=oecxaYBa; dmarc=none; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662408452; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bokwg7xdyQCTcQIFNpViOCCoKirBggqhDDEmWOHnoS4=; b=GCXEf7F0hgSsVN0oYrwdjK808/ZpQGJdYdqsBzOiSO54bKrLqT8VwT1kSNVNs4gCyZ9Yls c4BplcdKHp05VP/XNldrXJ8T/lCCYShPmwXOq1aCnD2/kKby3MWh9lZYsW+ivo5rqvETsN en0FYaNobfvad62Y81ufRej+ONt5ylI= X-Rspamd-Queue-Id: 31D084007D X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=oecxaYBa; dmarc=none; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspamd-Server: rspam10 X-Stat-Signature: 4kw5x544jn8g6xzpe3ejhk9k5juhhxq7 X-HE-Tag: 1662408452-933056 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 5 Sep 2022 21:38:13 +0800 Liu Shixin wrote: > If two or more threads call get_huge_zero_page concurrently, THP_ZERO_PAGE_ALLOC > may increased two or more times. But actually, this should only count > as once since the extra zero pages has been freed. Well, for better of for worse, Documentation/admin-guide/mm/transhuge.rst says thp_zero_page_alloc is incremented every time a huge zero page is successfully allocated. It includes allocations which where dropped due race with other allocation. Note, it doesn't count every map of the huge zero page, only its allocation. If you think this interprtation should be changed then please explain why, and let's be sure to update the documentation accordingly.