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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81AC2C433EF for ; Sat, 27 Nov 2021 09:20:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CCDAB6B0075; Sat, 27 Nov 2021 04:19:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C7D736B0078; Sat, 27 Nov 2021 04:19:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6CA66B007B; Sat, 27 Nov 2021 04:19:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0189.hostedemail.com [216.40.44.189]) by kanga.kvack.org (Postfix) with ESMTP id A82FB6B0075 for ; Sat, 27 Nov 2021 04:19:58 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 508C3812539B for ; Sat, 27 Nov 2021 09:19:48 +0000 (UTC) X-FDA: 78854162856.08.A7EA731 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf12.hostedemail.com (Postfix) with ESMTP id 3643910000BA for ; Sat, 27 Nov 2021 09:19:47 +0000 (UTC) Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4J1Qzv4ZsxzcbSf; Sat, 27 Nov 2021 17:19:39 +0800 (CST) Received: from kwepemm600002.china.huawei.com (7.193.23.29) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Sat, 27 Nov 2021 17:19:43 +0800 Received: from [10.174.185.187] (10.174.185.187) by kwepemm600002.china.huawei.com (7.193.23.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.20; Sat, 27 Nov 2021 17:19:42 +0800 Message-ID: <8ddeff27-267b-bc87-1061-9e7946fe9b42@huawei.com> Date: Sat, 27 Nov 2021 17:19:41 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US From: Peng Liang To: CC: , , , xiexiangyou 00584000 , zhengchuan , , chenwandun 00417970 Subject: Questions about page fault of memfd/shmem Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.185.187] X-ClientProxiedBy: dggeme713-chm.china.huawei.com (10.1.199.109) To kwepemm600002.china.huawei.com (7.193.23.29) X-CFilter-Loop: Reflected X-Stat-Signature: 84rrwm4n95ijzydqszircs5eg55wsur7 X-Rspamd-Queue-Id: 3643910000BA X-Rspamd-Server: rspam07 Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of liangpeng10@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=liangpeng10@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-HE-Tag: 1638004787-557657 X-Bogosity: Ham, tests=bogofilter, spamicity=0.147976, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi all, I'm a user-space developer and I want to use memfd to share some memory between parent and child processes. For the demo, it works well. However, I fount that the RSS of the process using memfd will grow up faster than that using anonymous mappings. Dig some memfd/shmem code and I find that memfd/shmem will allocate a page for a read page fault. For my use case, the process may allocate tens or even hundreds of GiB memory using memfd. So allocating all memory just because of reading it will has a great impact. Could memfd/shmem map to the global zero page instead of allocating a page for a read page fault? Thanks, Peng