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 9AE96C47073 for ; Sun, 7 Jan 2024 07:00:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A076C6B011C; Sun, 7 Jan 2024 02:00:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B4E96B025F; Sun, 7 Jan 2024 02:00:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A5D66B011D; Sun, 7 Jan 2024 02:00:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 773BE6B025F for ; Sun, 7 Jan 2024 02:00:07 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 45035A1453 for ; Sun, 7 Jan 2024 07:00:07 +0000 (UTC) X-FDA: 81651615654.12.E8327FB Received: from mail115-69.sinamail.sina.com.cn (mail115-69.sinamail.sina.com.cn [218.30.115.69]) by imf13.hostedemail.com (Postfix) with ESMTP id 736A820005 for ; Sun, 7 Jan 2024 07:00:02 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.69 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704610805; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ByizRyGDGo+oN/k/9Dua6jxTXwcaGVAO986Ht28pzEQ=; b=AmnIUCWSDo9cb2D1mohDvPDfrTEZii4nPEua/Dil0OCsM3j213Hnk78cu7TvJxKXlrHHpA 2HfAyCH3ey1jnVRZHiOkxnP4VJbCynuH5I3yDFdBThjUaybEkdUW6KSd3EBbyG2Vw0yhpd xG7uFx9n/Si4ARekqs8Er5VcaiojF6U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704610805; a=rsa-sha256; cv=none; b=TLx48bsLqOkbY7ttmGI13NZAb9iXLfORWm84E0wXMUtbRxHI+QfYA7WuG+AcQgsK5f/y7j kPzLcNdoQzk+sbcWOlcQZkYbwyhWZ5eTF2NVICPQn2R/wiockMjZtfYc/qDmaa5q2uPqkQ 2A8n54QoP1Q2rjLDrfWeEEm+Nc1693g= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of hdanton@sina.com designates 218.30.115.69 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.88.50.153]) by sina.com (10.75.12.45) with ESMTP id 659A4BE8000049C4; Sun, 7 Jan 2024 14:59:54 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 85437231457880 X-SMAIL-UIID: 25D86A25DE9648949CD5BA5B556EC8F0-20240107-145954-1 From: Hillf Danton To: Uladzislau Rezki , Wen Gu Cc: linux-mm@kvack.org, LKML Subject: Re: [PATCH v3 04/11] mm: vmalloc: Remove global vmap_area_root rb-tree Date: Sun, 7 Jan 2024 14:59:42 +0800 Message-Id: <20240107065942.3141-1-hdanton@sina.com> In-Reply-To: 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> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: j1yy5cymc6r5dwibafoyyms1a67kxapw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 736A820005 X-Rspam-User: X-HE-Tag: 1704610802-75583 X-HE-Meta: U2FsdGVkX1+tR/tU4+43asWN+VWOpp2/X2m/LY/utsVAcpS5L0zf077eSeg218kUZ7k2G3z9xnQDVR44k0j9rzqr8CLbGY5UYi9Dt4f7b91Ul7/1RFYlPwojyfXdSqQtXTU6zHEFnnlVeNQS4/pwoNQFUxFQkTeqGQlc1m79xP9/ENOUivnvZNcMg6TkcNpnN7NZCMo15/StOojR5tTMK6Bwsr+TbHXAgSEq9a9M9pJ2HfCquufLU39HbTdw/+L6CfnNFGLUJe6ouvspmSQsehpS2gIWyEJc0y9vvflqLC4CH4zLU8SOB69CwBr4LZ+QIwJGqwuMsS5tt/0HQgoRCCskfetfv+7QuMk7Y1dcXhI6AVROWZlOFvo7BbLDDPvxMIvJEC1bxBYwWwhktB/x2f1p6ni0nID1hlIMl8+JA6BqW+MuyPdWzJXP0dn6Ith7iXzfVgbPy5ljWaTs5DjDfYCGk8+d45UzHZcdNUG3jun5ttaJJd7mJw5UlC4MpQ86r1MfDt3tgdW3mFnH70xJI1dmQ1plh9O9Z0fmxNxqIdA5NMGivbVkD5v5288V+JGvfNwI0dhSyo2itICXZW5dK9sYVgO4zORJkIO8f0NMyAiqTdybNZfxJ/2Jk5zexpXpNiyA0bvg88i2+4w3cpUXSLLFuRGlCG1fj8Jdpb3f18IP0suqfAnIPI/3/usb+tpjGVCPkAZIlRUqUg4z8KwcDQCK3APgUJgs6NKFNx77XNg14mZtPa1Xjr/H/qJHG1UX/nRDdacUx3X+oXNbS5r3d3KNUFBYKzbWa9e0k1W2/U81ivHsnqxtcV2kA9Sxwy6a320hIzPOiw+FrU1Ixdc9wZSmNTE2m/l6bCRk5jXBn9UfcK0O9Or8MZ2n/Xw77rt7ZHfA6QCJdugZMwvvpgPES85K96c/jzITgLPKvdSvHVohahyOykkYRNDS8cAI591afoSSgAUEJ6u1MNH4x5t iHQ89Aiz loh+dSTqE/8riJHnu6foxrcsPsQliTPEitSXFr90r2riZt3UZLHGOINeUtM+CsakPZgo+xl9ydQYInu4GuxMpkg/4oePGE94HyCyp0kZvv+lNYyD4+BBPHQwZHboa8sd1hiN1YDYu1mgn/BpkC7VeRoIIIg== 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 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),