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 4110EC3DA6E for ; Mon, 8 Jan 2024 07:45:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5CE3A6B0082; Mon, 8 Jan 2024 02:45:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 57DF66B0083; Mon, 8 Jan 2024 02:45:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46CAA6B0085; Mon, 8 Jan 2024 02:45:26 -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 376FE6B0082 for ; Mon, 8 Jan 2024 02:45:26 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 063A8C0216 for ; Mon, 8 Jan 2024 07:45:26 +0000 (UTC) X-FDA: 81655358652.01.BE9F2C8 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) by imf30.hostedemail.com (Postfix) with ESMTP id 027828000C for ; Mon, 8 Jan 2024 07:45:22 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf30.hostedemail.com: domain of guwen@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=guwen@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704699924; a=rsa-sha256; cv=none; b=RSXRFvfsRjG253/fVSlZjd0KVAv2scd0uGj9yfBx9QTxY0B8lXQtguqKX/7Ej+DeLsOyuT 2ZJRaRBVvhuYW495VLMURjb3viRXvHjOLO/GRQouau0863F8O13Dx9qL63ghTXyfLkunLm h3MFdvvT5xS2PkjOdMyt2Zdq+dKt8+U= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf30.hostedemail.com: domain of guwen@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=guwen@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704699924; 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=XJZX76FVRqYrGbf3jNI/wGMXPrm7pOY3mkYvfIE7zf4=; b=xhNluZsbdiJNKNjMQPbdYmWcXFtXlpqskL7Oo6oXHx6jX3KRLxNgS9M87Ph5IWBLVZ7+O/ tBhqCmGDSMQaO+OTkBPqb5Ek4voMdtV2YgCruGokhdzRzy0GFAHc5Ji/LsiSrbdAeECAzR cOHFPlvCvutU8sGOHyiiBboN5/FG7BU= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045168;MF=guwen@linux.alibaba.com;NM=1;PH=DS;RN=4;SR=0;TI=SMTPD_---0W-9bfT6_1704699918; Received: from 30.221.132.24(mailfrom:guwen@linux.alibaba.com fp:SMTPD_---0W-9bfT6_1704699918) by smtp.aliyun-inc.com; Mon, 08 Jan 2024 15:45:19 +0800 Message-ID: <328501ae-828f-4aa8-baab-833573c010e7@linux.alibaba.com> Date: Mon, 8 Jan 2024 15:45:18 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 04/11] mm: vmalloc: Remove global vmap_area_root rb-tree To: Hillf Danton , Uladzislau Rezki Cc: linux-mm@kvack.org, LKML References: <20240102184633.748113-1-urezki@gmail.com> <20240102184633.748113-5-urezki@gmail.com> <238e63cd-e0e8-4fbf-852f-bc4d5bc35d5a@linux.alibaba.com> <52766da2-41de-41ce-b60b-1118da343b8a@linux.alibaba.com> <20240107065942.3141-1-hdanton@sina.com> From: Wen Gu In-Reply-To: <20240107065942.3141-1-hdanton@sina.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 027828000C X-Stat-Signature: 38wejeborfpatdzst9dmh3wejodznjpa X-Rspam-User: X-HE-Tag: 1704699922-617264 X-HE-Meta: U2FsdGVkX1/xzifRetlo1+usqgD2qHnAJRMfwEPIf1bfctwbMf3UmqK1A6hMbNBwmbDF8t5Dz+ezKmQqUkdK97tzt327yE1FEe7rPugHX13Os4gN2WtcGeTzkUxyeyBA91V9HUBHbCLCb2S5tU88rIUw6CbHBP1uugNTDXBAU8gmXLxuTzCwWJxR0ebYpTAIglp3fLLYUjermbodONm0DWs0AxldIm986HrkAgMoD693rovuie4TnMy1h3+XAIUxAyWQmgjedBJUqLWoW60G0KPUc2D+kFLW8KQPt1sjlQ0yB9jiQAX1JYmc6xx0Ne10tXwsifyN+je5irKZ6uSVrOxk/Awyaq3pSQ5tna/wiSHYowF67UwUjunIno8OsywiSCKZIzm6XBA6MqnmwneoBvnvj0kYwRP7k61pBjOpabuFDfLKlY1DdOThrn+TDFlVZV4Ha6igbGXRh6CrIgNsBjKP7eSZ+mlTjoSg5Zb0CTlJJlqTHMDbyJ/QIrLquQa5Diljz1Y7xc5iOmdObyogL7vxtKGGBiVhs6PUG/MzA25UKm4zxaLyafvzdVRWD/r+vDdhWb8Dx8eajv6DtPCI1tM0P1AF88Ce6PqYbULDo8O/NqT12BUPfv4qpa6az5YlKlxMra7Ovjzahtjd5AmFAAdQkAfKl5SXLf4tHIwTYaQ5pSd1exLYOfLGJrJjk3urymw+xGqRpuYR7GaBPHfdedtZi75i7XeM1t+fRWL9lrrpfxLa46j+Kh4hSy5WOsK6y9h0/AQ7yt49/l8tmZ5/++v5RIcSy1Y0S2j23P3Mh5rH3cPu1ruL4vhkGktNbKorTb4qIi+U1KqdTSm2BiuNde3FHtnoXefdC+55c1U0tEQ7GaCzjO4+fNEcZAiX0tw9fHeWSHS4sB7C4R1U/sDT3pWbWOzdZQCSvP5+WfitnIK2e4Ivk88WqmJ1dimRpZL56EDnK38GJPMGYwqLVzC ZvVRJB75 oH2BF83Jzjnt11JRbO5OONTYr36b45LlFQUu/pzoaPiP6zUAR8/RqydDXgwE54xaZbaSF9NWoZ4339XDt71xlCCn06dubZHuX5ymbEdALzElcE8heMbb0mKUoDm5yPBu9m2TBWkQ5PXfqpOAKZz2kCmW7HX6P0mE28sKWJkT7O0hQWenwKs0dgDeYHiIz+mU9jOt6b7xV+l5oFIScKtiMfDUHnOBbT4QjJcf3xHHmKmxvQZ0jczUYgxcwtQ== 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/1/7 14:59, Hillf Danton wrote: > On Sat, 6 Jan 2024 17:36:23 +0100 Uladzislau Rezki >>> >>> Thank you! I tried the patch, and it seems that the wait for rwlock_t >>> also exists, as much as using spinlock_t. (The flamegraph is attached. >>> Not sure why the read_lock waits so long, given that there is no frequent >>> write_lock competition) >>> >>> vzalloced shmem(spinlock_t) vzalloced shmem(rwlock_t) >>> Requests/sec 583729.93 460007.44 >>> >>> So I guess the overhead in finding vmap area is inevitable here and the >>> original spin_lock is fine in this series. >>> >> I have also noticed a erformance difference between rwlock and spinlock. >> So, yes. This is what we need to do extra if CONFIG_HARDENED_USERCOPY is >> set, i.e. find a VA. > > See if read bias helps to understand the gap between spinlock and rwlock. > > --- x/kernel/locking/qrwlock.c > +++ y/kernel/locking/qrwlock.c > @@ -23,7 +23,7 @@ void __lockfunc queued_read_lock_slowpat > /* > * Readers come here when they cannot get the lock without waiting > */ > - if (unlikely(in_interrupt())) { > + if (1) { > /* > * Readers in interrupt context will get the lock immediately > * if the writer is just waiting (not holding the lock yet), Thank you for the idea! Hillf. IIUC, the change makes read operations more likely to acquire lock and modified fairness to favor reading. The test in my scenario shows: vzalloced shmem with spinlock_t rwlock_t rwlock_t(with above change) Requests/sec 564961.29 442534.33 439733.31 In addition to read bias, there seems to be other factors that cause the gap, but I haven't figured it out yet.. Thanks, Wen Gu