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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 24A83C433DB for ; Fri, 19 Feb 2021 08:52:49 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0541B64D92 for ; Fri, 19 Feb 2021 08:52:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0541B64D92 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4DhlhZ2Dzlz3cPN for ; Fri, 19 Feb 2021 19:52:46 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=45.249.212.190; helo=szxga04-in.huawei.com; envelope-from=dingtianhong@huawei.com; receiver=) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Dhlh96chYz30KW for ; Fri, 19 Feb 2021 19:52:21 +1100 (AEDT) Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Dhldj4s0gzlMgR; Fri, 19 Feb 2021 16:50:17 +0800 (CST) Received: from [10.174.177.80] (10.174.177.80) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.498.0; Fri, 19 Feb 2021 16:52:05 +0800 Subject: Re: [PATCH v12 13/14] mm/vmalloc: Hugepage vmalloc mappings To: Nicholas Piggin , Andrew Morton , References: <20210202110515.3575274-1-npiggin@gmail.com> <20210202110515.3575274-14-npiggin@gmail.com> <1613720396.pnvmwaa8om.astroid@bobo.none> From: Ding Tianhong Message-ID: <913cd34a-453c-ae66-ff87-4b0c74c98eb6@huawei.com> Date: Fri, 19 Feb 2021 16:52:05 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: <1613720396.pnvmwaa8om.astroid@bobo.none> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.80] X-CFilter-Loop: Reflected X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Jonathan Cameron , Rick Edgecombe , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 2021/2/19 15:45, Nicholas Piggin wrote: > Excerpts from Ding Tianhong's message of February 19, 2021 1:45 pm: >> Hi Nicholas: >> >> I met some problem for this patch, like this: >> >> kva = vmalloc(3*1024k); >> >> remap_vmalloc_range(xxx, kva, xxx) >> >> It failed because that the check for page_count(page) is null so return, it break the some logic for current modules. >> because the new huge page is not valid for composed page. > > Hey Ding, that's a good catch. How are you testing this stuff, do you > have a particular driver that does this? > yes, The driver would get a memory from the vmalloc in kernel space, and then the physical same memory will mmap to the user space. The drivers could not work when applying this patch. >> I think some guys really don't get used to the changes for the vmalloc that the small pages was transparency to the hugepage >> when the size is bigger than the PMD_SIZE. > > I think in this case vmalloc could allocate the large page as a compound > page which would solve this problem I think? (without having actually > tested it) > yes, i think the __GFP_COMP flag could fix this. >> can we think about give a new static huge page to fix it? just like use a a new vmalloc_huge_xxx function to disginguish the current function, >> the user could choose to use the transparent hugepage or static hugepage for vmalloc. > > Yeah that's a good question, there are a few things in the huge vmalloc > code that accounts things as small pages and you can't assume large or > small. If there is benefit from forcing large pages that could certainly > be added. > The vmalloc transparent is good, but not fit every user scenes, some guys like to use the deterministic function for performance critical area. Thanks Ding > Interestingly, remap_vmalloc_range in theory could map the pages as > large in userspace as well. That takes more work but if something > really needs that for performance, it could be done. > > Thanks, > Nick > . >