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 52FF9C433DB for ; Fri, 19 Feb 2021 08:52:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9D7B664E44 for ; Fri, 19 Feb 2021 08:52:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D7B664E44 Authentication-Results: mail.kernel.org; dmarc=none (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 DBBF68D0002; Fri, 19 Feb 2021 03:52:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D6E188D0001; Fri, 19 Feb 2021 03:52:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C83FE8D0002; Fri, 19 Feb 2021 03:52:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0001.hostedemail.com [216.40.44.1]) by kanga.kvack.org (Postfix) with ESMTP id B2CCA8D0001 for ; Fri, 19 Feb 2021 03:52:20 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7AA298249980 for ; Fri, 19 Feb 2021 08:52:20 +0000 (UTC) X-FDA: 77834400840.29.254ECE0 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf01.hostedemail.com (Postfix) with ESMTP id 42FC420001F2 for ; Fri, 19 Feb 2021 08:52:17 +0000 (UTC) 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 , CC: Christophe Leroy , Christoph Hellwig , Jonathan Cameron , , , , Rick Edgecombe 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 42FC420001F2 X-Stat-Signature: c3danfbecw8s3rmzddpn5roha3rtuy8o Received-SPF: none (huawei.com>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=szxga04-in.huawei.com; client-ip=45.249.212.190 X-HE-DKIM-Result: none/none X-HE-Tag: 1613724737-106273 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 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 > . >