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 11EDBE7716D for ; Wed, 4 Dec 2024 09:21:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D9166B007B; Wed, 4 Dec 2024 04:21:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7891E6B0082; Wed, 4 Dec 2024 04:21:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 650D16B0083; Wed, 4 Dec 2024 04:21:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 46C826B007B for ; Wed, 4 Dec 2024 04:21:22 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A575DC0E64 for ; Wed, 4 Dec 2024 09:21:21 +0000 (UTC) X-FDA: 82856732910.04.4161AB4 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf20.hostedemail.com (Postfix) with ESMTP id EAFB31C0004 for ; Wed, 4 Dec 2024 09:21:02 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf20.hostedemail.com: domain of zuoze1@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=zuoze1@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733304065; 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=YVaq/g0JaC9umzkfES6LoiNd9+ir2XwuhHT/IIpWyS8=; b=oiDr2EUN7vAeMyhf3ZVoidyEDnIu3utPSVB9rn7L3jeIZH46EfVqJjVa4aZFwJShdqOS1o g9Z7VOeSmvKPDyZ+V11NGG0TjNW8xmeatFcb6ybFIn+fUoAsU9L91NldcWBPK90/s1dts/ 3SQ5dWbD54f9C/loTalz43pqNv+y3MQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733304065; a=rsa-sha256; cv=none; b=e1goekcFVkppssn40QnvtssPZKxbycbpUPAtcFQp6F4RvlAS3WiameiwD8elmuJdYKtCVo y4iZat2cPym1U53K7W6cJr9kyGbFzhrt8eWUNCsSIG3G1iqv+CX8qHyREMQ6cc3AolX+ji f9IrGSf41RITHJmedlhUAoasXUGxlQc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf20.hostedemail.com: domain of zuoze1@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=zuoze1@huawei.com Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4Y3BlF2yLXz1V5SG; Wed, 4 Dec 2024 17:18:17 +0800 (CST) Received: from kwepemg500008.china.huawei.com (unknown [7.202.181.45]) by mail.maildlp.com (Postfix) with ESMTPS id CDA3514011D; Wed, 4 Dec 2024 17:21:13 +0800 (CST) Received: from [10.174.177.186] (10.174.177.186) by kwepemg500008.china.huawei.com (7.202.181.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 4 Dec 2024 17:21:12 +0800 Message-ID: <2dae287b-c645-3773-4f99-fd44902ae589@huawei.com> Date: Wed, 4 Dec 2024 17:21:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH -next] mm: usercopy: add a debugfs interface to bypass the vmalloc check. To: Uladzislau Rezki , Matthew Wilcox , Kefeng Wang CC: , , , , References: <92768fc4-4fe0-f74a-d61c-dde0eb64e2c0@huawei.com> <76995749-1c2e-4f78-9aac-a4bff4b8097f@huawei.com> From: zuoze In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.186] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemg500008.china.huawei.com (7.202.181.45) X-Rspamd-Queue-Id: EAFB31C0004 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: sd1nxcqiw6gi5y4uc4eedibhx6xwn9pw X-HE-Tag: 1733304062-248175 X-HE-Meta: U2FsdGVkX19+Ioc5KZ49bcxLw8/Yh1k/FMr8zmGolS7W63Z3UWda5Qjx+kEcuFC+VkujBrGyoYYBrgpYbuF/kasClAkWHQ5BJDZRWisVN/EdhbZd7brZ8HdirP1UESgxkTdF1xuGHRNkQPby04axiPqmtrQ7hudk9/xa0ve0mwUi4Bcv5gUZwEB26ZaoYeaDcdad0mDacnJicAuByRSqbhXuG1XZ/JCagHR2ffF7+LjxtPGIhQkVE2ox6igt5j3yEJ3cPIPuz8ZRfkQzhFt6xJXbIwlX3ZlM4jEylhV0qEo+0A+xEWN3ivU6yxGz+rfjonukjEJ9Dpa9zztGBCtdP1LiX8sD3rWn+B8ij5HFkf8Yl70ofpxhGah5QGuO9m300HX77za95Ofkm5gJiVOFPmncIPGVk+5SGgKzQCZzoK05jGuKiRcBg4AtPyhpxd2oi+ju1+u24BqcVPUfzIWcGxLe9sJGyh/cNT9TUOx+STmNMQkm1G9ZlVPy8pb0OLmPaw+FH1GbGAhUTu6AjHwk4wa4gFlukZN+oDKGK2mcEkF6V7l2XHpydhzQ+VhGZ0MNzoa3x5a615pfRvMk97pGNzSveuIJl+voEiTqBXVkE4ruw6Lq7iEFR4ecejTA73whn7ZoaT7UsL0ea/iuj77h5qJZ7tAgkXU4VrpNMJqNJqM/iuOltwSSuJnEAHvXKVHaNN6OYdqEO09yS0R39UXp3h+MvMxh6YQj9aorrGepRhaXd9WcNWzUZFpkYcQdziY2tW9gxhpm5Kolh2x/S6xgeXVNvSKsWNpJqCRFzpyzS86pNAvvmnw1EO4o7gbAheNVR2tE0dKrMm7zwcrENNgQHPtifwuACigvIOaQdBKVrj1hDWe352ya7fVSCtLJbp9OUsisosYOxa+wKMwSJ+FOK8XqYHGDNHqLvU4Mk1XUECKKXVadLUN0Q0wv4nexjk9KYDLkvBcnAsS4sIudGG/ TUtYpgW9 tjEERlpVCCvMyjazZ5S0k1QDPiMA6g8YSF/ZrXJfhyg8pCZXzfGRhdyfuke0343ZkaqPy/XNZtABPZ2kO3or5cfGUhEJ5j/yF2UIz4moRsD+6pY0MMag21eI8b4HIJeibOmnH6VpKuFEI2h0Ma8FZPDkSUw== 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: 在 2024/12/4 15:55, Uladzislau Rezki 写道: > On Tue, Dec 03, 2024 at 07:56:34PM +0000, Matthew Wilcox wrote: >> On Tue, Dec 03, 2024 at 08:02:26PM +0100, Uladzislau Rezki wrote: >> >> I think there are a few other things we can try here. >> >> First, if the copy is small (and I still don't have an answer to that >> ...), we can skip the vmalloc lookup if the copy doesn't cross a page >> boundary. >> >> Second, we could try storing this in a maple tree rather than an rbtree. >> That gives us RCU protected lookups rather than under a spinlock. >> >> It might even be worth going to a rwlock first, in case the problem is >> that there's severe lock contention. >> >> But I've asked for data on spinlock contention and not received an >> answer on that either, so I don't know what to suggest. >> > I think, it is not about contention. It is about the extra "attached > load" when a data is heavily copied force and back. On each copy path > you need to do a scan. Maple tree is not that something can help here :) > > Indeed, no contention data. Zuoze, please share this if you can. We have enabled perf lock contention and are currently debugging the environment. We will share the results as soon as we have them. > > -- > Uladzislau Rezki