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 836A6E64AB3 for ; Tue, 3 Dec 2024 14:10:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 148276B0089; Tue, 3 Dec 2024 09:10:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F91B6B009B; Tue, 3 Dec 2024 09:10:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F02156B009C; Tue, 3 Dec 2024 09:10:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D2E2C6B0089 for ; Tue, 3 Dec 2024 09:10:36 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 83572ADFF6 for ; Tue, 3 Dec 2024 14:10:36 +0000 (UTC) X-FDA: 82853832642.19.A082B9A Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf21.hostedemail.com (Postfix) with ESMTP id 854901C001D for ; Tue, 3 Dec 2024 14:10:08 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733235021; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xE0fS7y375NZYFjuRbPeA1TvZzRMQrinTtC8maDue8g=; b=FOpjpe3NdaqkiASxbWV7N9Utn8qL+Snug01BCCpVLwLKG8r2WSEkjq0BesVGyH6zEXbqiL pRFAq8LxySPyGEJh4yBbwLpSpmQm+zhpIxDivAacrZbTgTUyZzsxRoluWodc/rXnyLi3Hx WlDjgukAT7CA5cNDw6AVmTU3x15h4ZQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733235021; a=rsa-sha256; cv=none; b=yx/wXyfwnoL6eR8nondSYJwLAmGLALromoUaKu+8PPzuksjPc4sIuE4jL+XJszeibJto9J o1At/AHM6+FDU/lKRoSjv1wrxwjpTJP7iT9ZJAjt2hbtRqtusLep8sK6NItkEJ/vyUtKBO X37j30aUOG2Kf8YUm3wV19eSt8a38R8= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Y2jGh5pWRz1JDX1; Tue, 3 Dec 2024 22:10:20 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 731A314037F; Tue, 3 Dec 2024 22:10:27 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 3 Dec 2024 22:10:26 +0800 Message-ID: Date: Tue, 3 Dec 2024 22:10:26 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH -next] mm: usercopy: add a debugfs interface to bypass the vmalloc check. To: Uladzislau Rezki CC: zuoze , Matthew Wilcox , , , , , References: <20241203023159.219355-1-zuoze1@huawei.com> <57f9eca2-effc-3a9f-932b-fd37ae6d0f87@huawei.com> <92768fc4-4fe0-f74a-d61c-dde0eb64e2c0@huawei.com> <76995749-1c2e-4f78-9aac-a4bff4b8097f@huawei.com> Content-Language: en-US From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Queue-Id: 854901C001D X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: kykkpdm9mfdwccsbhoirtrirwbgr54kq X-HE-Tag: 1733235008-581840 X-HE-Meta: U2FsdGVkX1+qDeKiFAfV8v7brfs6JGbnZv3VwtbbhdGKLH9kW0sDyzxzvCXwe8QSfkJXb+pXg0bRuFy7UuK4SqtFSFhPnjlYdfRgcOIKtazUuLOlw/W7AZsmpLswVI4JsfKE/VtX7Jt8VbYgnfYHJ6kT44UCZw3NDHie2a1AO1YUpdM8zRi8beJcKoQmm59qSL0n8aG8tBc7nGg4smdJWfRSaGwFksqelEl/XBIASKQygcfgR2hW1DrwfZ5H6QuFTvYIzkfo74emEa020JVSFWqrLa9L6VsT7DyLGhjvKyeBraAOHZdJrnLAu8vKq/nX3vOvX6Npp5EyT0y1PR3wbwtua2QccErHlRxavKHttxwLIOweeB1DiksTsWV9f9iOdN0bB9kAIvQCC6wX8cNF4BsMFmP8tJuHP5/LABoNEpPWQVDHwf+VXxC2D4QnrYBZAL9OQLbCxv3BW2vydlW9Ku3kKUUgKhp3/NDfDVf5kXJtJe8se7fETqfgt6Ng8P1QiHlxc+ECv9zxZkKLWpbtNGG6y69L3WIiAR/jz8y/EDY7MXdlHsmbUljRNmpa/sjztFFErcFKJjGdCpoI9WLYDK2RMikeR3PDv71Iv9n06LOA0I3JV6HS3nwZYEPdR+9jWB3NGGixPJ7LVBOv+TpRORs7n+XSK6RG9LI5eMe+HY6FDl7tagOC5rGbjJ9O8CqB2GAcqq2D1pS8At8l4VI/o2nrZ2sFLZCxEemi2364JJDQf6ORhQ9iapZvxAp/zjTVNfEhbjWYf93csmc+7H3G+1rDlAVRYDKQESVPsn2/iCbpD/s1+zls6+sXhXmHsieJPKHBshz15rIyjysWhA/8kqCvfTpOdP/pRbAjylIcVAnztD0lHhy9wR1xeptS2M9UrILAkMLkijqrXjsOOHquH09EpN6rY1NG6jsmuAgHjUHBGvUklpQr/RV9t5stjDmdlV2y9spifyxLAs6pEbB Z9oYhvSp /+UmUCH8k2Z/pfKt9qIr8cqfr8hd7HJ4QpOTIDyNoqfm0zkTQFT8HVdlKvpcUyf+uqQT9BimHphR+IqOAHRFxxE545xFV6r/52MTKSti55fyUrIys6OyEFYzVhxOZc3/dkrnUAcQNbv/FTHS/E1e1zaa2gGkLeXmesTto8XpBsZnjPgBuUV4iz7Kj/Gm6M/yXEzqE 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: List-Subscribe: List-Unsubscribe: On 2024/12/3 21:51, Uladzislau Rezki wrote: > On Tue, Dec 03, 2024 at 09:45:09PM +0800, Kefeng Wang wrote: >> >> >> On 2024/12/3 21:39, Uladzislau Rezki wrote: >>> On Tue, Dec 03, 2024 at 09:30:09PM +0800, Kefeng Wang wrote: >>>> >>>> >>>> On 2024/12/3 21:10, zuoze wrote: >>>>> >>>>> >>>>> 在 2024/12/3 20:39, Uladzislau Rezki 写道: >>>>>> On Tue, Dec 03, 2024 at 07:23:44PM +0800, zuoze wrote: >>>>>>> We have implemented host-guest communication based on the TUN device >>>>>>> using XSK[1]. The hardware is a Kunpeng 920 machine (ARM architecture), >>>>>>> and the operating system is based on the 6.6 LTS version with kernel >>>>>>> version 6.6. The specific stack for hotspot collection is as follows: >>>>>>> >>>>>>> -  100.00%     0.00%  vhost-12384  [unknown]      [k] 0000000000000000 >>>>>>>     - ret_from_fork >>>>>>>        - 99.99% vhost_task_fn >>>>>>>           - 99.98% 0xffffdc59f619876c >>>>>>>              - 98.99% handle_rx_kick >>>>>>>                 - 98.94% handle_rx >>>>>>>                    - 94.92% tun_recvmsg >>>>>>>                       - 94.76% tun_do_read >>>>>>>                          - 94.62% tun_put_user_xdp_zc >>>>>>>                             - 63.53% __check_object_size >>>>>>>                                - 63.49% __check_object_size.part.0 >>>>>>>                                     find_vmap_area >>>>>>>                             - 30.02% _copy_to_iter >>>>>>>                                  __arch_copy_to_user >>>>>>>                    - 2.27% get_rx_bufs >>>>>>>                       - 2.12% vhost_get_vq_desc >>>>>>>                            1.49% __arch_copy_from_user >>>>>>>                    - 0.89% peek_head_len >>>>>>>                         0.54% xsk_tx_peek_desc >>>>>>>                    - 0.68% vhost_add_used_and_signal_n >>>>>>>                       - 0.53% eventfd_signal >>>>>>>                            eventfd_signal_mask >>>>>>>              - 0.94% handle_tx_kick >>>>>>>                 - 0.94% handle_tx >>>>>>>                    - handle_tx_copy >>>>>>>                       - 0.59% vhost_tx_batch.constprop.0 >>>>>>>                            0.52% tun_sendmsg >>>>>>> >>>>>>> It can be observed that most of the overhead is concentrated in the >>>>>>> find_vmap_area function. >>>>>>> ... >> > Thank you. Then you have tons of copy_to_iter/copy_from_iter calls > during your test case. Per each you need to find an area which might > be really heavy. Exactly, no vmalloc check before 0aef499f3172 （"mm/usercopy: Detect vmalloc overruns"), so no burden in find_vmap_area in old kernel. > > How many CPUs in a system you have? > 128 core