Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp3785715rwb; Mon, 5 Sep 2022 19:10:23 -0700 (PDT) X-Google-Smtp-Source: AA6agR6quweJpeF7Cv30XZANtOAz0bHo7hHw0p0elEtuyyTboiKGT/NKN/3k0W0l5NlAnJrW+U8O X-Received: by 2002:a17:907:868b:b0:741:8f6b:187c with SMTP id qa11-20020a170907868b00b007418f6b187cmr28479029ejc.188.1662430223191; Mon, 05 Sep 2022 19:10:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662430223; cv=none; d=google.com; s=arc-20160816; b=GzFSLXC7w6QiYVKpG9P1Fm8xG/Fb8aGjrzmY9TLTaWEX+EVunr4AfJC2lnWPETUr3n vEo4FOjlps7g6h8plkDanmzY3G4A2sLOPfE+7VgyaPwJsS+907pwJy7/Txk0BzEKIHL6 +e4WY+uVUbs8ldIyw90wxpVGJxZjT8LLNnRTrRiAoPLL99Wrflj9cmTgDpICwilCnXYH Qyd36CxufoRS90rtFC8/F/6lfDgpPNm74vSbWPF0mR3/xc/+eX5lLMlwRPqdcLNlh6xa T3DBaaTsCJfsKo0LBDUvUcZU8gajinftL+H1N456wmmAb/8UJdcpzbx+gEZj3YNXkFrT cPsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=1Doatvx8kfElS9UT6gUGhoGXIwC+klPzc9c85tuuLN4=; b=HfDb224c3Xog9QocMq9JsfS5ir4/8rDqs4BLyqQ2VN+zZNFZcIAxmR75opxBMQf8JK 2sXjI4TkdU/0CnXe0fMSa7b/5ArtCwe61NNPLT7P/NZu6DookPgQoBHhEIahAaA2YoTd Nm7V8CRNn6vgdwQDrHGjo9fF5W8YjJ30QLFVTOAB5uk38FXQs/vHVN4FquOmeQ7IJE12 0qTtqlBR83oOn1afhSlMYHvPJ41DTdyGoxT5kqBGkqceZ1WxiRJVWedke2FTkSWknvmp 0O9Rl76ndVPGCyMqwpjj7GYnsm65xhCajOkndHj4qLgOsQm+vBcsbz/RdQ3Ua8xxcAF8 +2Ww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hq16-20020a1709073f1000b007384c1db86fsi8809380ejc.60.2022.09.05.19.09.56; Mon, 05 Sep 2022 19:10:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232498AbiIFBw3 (ORCPT + 99 others); Mon, 5 Sep 2022 21:52:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231893AbiIFBw1 (ORCPT ); Mon, 5 Sep 2022 21:52:27 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF11866A47 for ; Mon, 5 Sep 2022 18:52:25 -0700 (PDT) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4MM7Zr6kw2zkX54; Tue, 6 Sep 2022 09:48:36 +0800 (CST) Received: from dggpemm100009.china.huawei.com (7.185.36.113) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 6 Sep 2022 09:52:23 +0800 Received: from [10.174.179.24] (10.174.179.24) by dggpemm100009.china.huawei.com (7.185.36.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 6 Sep 2022 09:52:23 +0800 Subject: Re: [PATCH] mm/huge_memory: prevent THP_ZERO_PAGE_ALLOC increased twice To: Andrew Morton References: <20220905133813.2253703-1-liushixin2@huawei.com> <20220905130728.1e814d185b189faece6f2c2f@linux-foundation.org> CC: , , Kefeng Wang From: Liu Shixin Message-ID: Date: Tue, 6 Sep 2022 09:52:23 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20220905130728.1e814d185b189faece6f2c2f@linux-foundation.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm100009.china.huawei.com (7.185.36.113) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/9/6 4:07, Andrew Morton wrote: > 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. > > . Thanks for your explanation. I misunderstood the meaning of thp_zero_page_alloc before. Although the rules are clearly explained in the documentation, I think that this variable should only incremented when a huge zero page used for thp is successfully allocated and the pages dropped due race should skip increment. It seems strange to count in all allocations. If there's something I still misunderstand, please point it out, thanks. Thanks,