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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F3C70C6FA83 for ; Mon, 5 Sep 2022 20:07:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231301AbiIEUHc (ORCPT ); Mon, 5 Sep 2022 16:07:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229616AbiIEUHb (ORCPT ); Mon, 5 Sep 2022 16:07:31 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 42C521EEEF for ; Mon, 5 Sep 2022 13:07:30 -0700 (PDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id D21A2601BD for ; Mon, 5 Sep 2022 20:07:29 +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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.