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 X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4920C433E0 for ; Fri, 26 Mar 2021 01:42:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C49361A3A for ; Fri, 26 Mar 2021 01:42:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C49361A3A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CD3E16B0036; Thu, 25 Mar 2021 21:42:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C84996B006E; Thu, 25 Mar 2021 21:42:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B25336B0070; Thu, 25 Mar 2021 21:42:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id 9046A6B0036 for ; Thu, 25 Mar 2021 21:42:54 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 58C0718004A71 for ; Fri, 26 Mar 2021 01:42:54 +0000 (UTC) X-FDA: 77960326668.35.4630A63 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf22.hostedemail.com (Postfix) with ESMTP id 209F5C0001FE for ; Fri, 26 Mar 2021 01:42:49 +0000 (UTC) Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4F64Rq6LNJz9tDK; Fri, 26 Mar 2021 09:40:39 +0800 (CST) Received: from [10.174.178.163] (10.174.178.163) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.498.0; Fri, 26 Mar 2021 09:42:37 +0800 Subject: Re: [PATCH 0/8] make hugetlb put_page safe for all calling contexts To: Mike Kravetz , , CC: Roman Gushchin , Michal Hocko , Shakeel Butt , Oscar Salvador , David Hildenbrand , Muchun Song , David Rientjes , Peter Zijlstra , Matthew Wilcox , HORIGUCHI NAOYA , "Aneesh Kumar K . V" , Waiman Long , Peter Xu , Mina Almasry , "Hillf Danton" , Andrew Morton References: <20210325002835.216118-1-mike.kravetz@oracle.com> From: Miaohe Lin Message-ID: <7c74ca0d-59fc-9dc2-6e4c-4357ad76649f@huawei.com> Date: Fri, 26 Mar 2021 09:42:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210325002835.216118-1-mike.kravetz@oracle.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.163] X-CFilter-Loop: Reflected X-Stat-Signature: bfpripnnq441aqky3b9k6rgu5eruoham X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 209F5C0001FE Received-SPF: none (huawei.com>: No applicable sender policy available) receiver=imf22; identity=mailfrom; envelope-from=""; helo=szxga07-in.huawei.com; client-ip=45.249.212.35 X-HE-DKIM-Result: none/none X-HE-Tag: 1616722969-104112 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: Hi: On 2021/3/25 8:28, Mike Kravetz wrote: > This effort is the result a recent bug report [1]. In subsequent > discussions [2], it was deemed necessary to properly fix the hugetlb Many thanks for the effort. I have read the discussions and it is pretty long. Maybe it would be helpful if you give a brief summary here? > put_page path (free_huge_page). This RFC provides a possible way to trival: Not RFC here. > address the issue. Comments are welcome/encouraged as several attempts > at this have been made in the past. > > This series is based on v5.12-rc3-mmotm-2021-03-17-22-24. At a high > level, the series provides: > - Patches 1 & 2 from Roman Gushchin provide cma_release_nowait() trival: missing description of the Patches 3 ? > - Patches 4, 5 & 6 are aimed at reducing lock hold times. To be clear > the goal is to eliminate single lock hold times of a long duration. > Overall lock hold time is not addressed. > - Patch 7 makes hugetlb_lock and subpool lock IRQ safe. It also reverts > the code which defers calls to a workqueue if !in_task. > - Patch 8 adds some lockdep_assert_held() calls > > [1] https://lore.kernel.org/linux-mm/000000000000f1c03b05bc43aadc@google.com/ > [2] http://lkml.kernel.org/r/20210311021321.127500-1-mike.kravetz@oracle.com > > RFC -> v1 > - Add Roman's cma_release_nowait() patches. This eliminated the need > to do a workqueue handoff in hugetlb code. > - Use Michal's suggestion to batch pages for freeing. This eliminated > the need to recalculate loop control variables when dropping the lock. > - Added lockdep_assert_held() calls > - Rebased to v5.12-rc3-mmotm-2021-03-17-22-24 > > Mike Kravetz (6): > hugetlb: add per-hstate mutex to synchronize user adjustments > hugetlb: create remove_hugetlb_page() to separate functionality > hugetlb: call update_and_free_page without hugetlb_lock > hugetlb: change free_pool_huge_page to remove_pool_huge_page > hugetlb: make free_huge_page irq safe > hugetlb: add lockdep_assert_held() calls for hugetlb_lock > > Roman Gushchin (2): > mm: cma: introduce cma_release_nowait() > mm: hugetlb: don't drop hugetlb_lock around cma_release() call > > include/linux/cma.h | 2 + > include/linux/hugetlb.h | 1 + > mm/cma.c | 93 +++++++++++ > mm/cma.h | 5 + > mm/hugetlb.c | 354 +++++++++++++++++++++------------------- > mm/hugetlb_cgroup.c | 8 +- > 6 files changed, 294 insertions(+), 169 deletions(-) >