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 5F548C3DA6E for ; Mon, 8 Jan 2024 18:37:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C71996B0082; Mon, 8 Jan 2024 13:37:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C22526B0083; Mon, 8 Jan 2024 13:37:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AEA016B0087; Mon, 8 Jan 2024 13:37:48 -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 9C5FE6B0082 for ; Mon, 8 Jan 2024 13:37:48 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 66AC58031A for ; Mon, 8 Jan 2024 18:37:48 +0000 (UTC) X-FDA: 81657002616.14.9A46897 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf02.hostedemail.com (Postfix) with ESMTP id 72F7880003 for ; Mon, 8 Jan 2024 18:37:45 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RumVHh5T; spf=pass (imf02.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704739065; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/Fn/vm7iOQ6ScVuyrdABBMSC9h+mKMI7gV8fitPzaT0=; b=Kn9RjVT4UfhFeBoQrnr1zVEnnt+F2cSRm9toadJHhahaR3+li519TaVSY3I6Tg1GihrYS2 V1p/aGk2giB80Fh7QTfClLMqrLQHjVh1MMoRtDHn4YLkh+7DPScVuQtLn/bzCAu2f89bKX KqwTihRcPbNoft85rL5ccRRYGQTNdPs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704739065; a=rsa-sha256; cv=none; b=W6SYWqnpgiKbo7EMzYWyB1RbVhA6ieifPNGILtWIQ3PAI8BU3vvIubHF7lnsOrrufZ1SM0 H6wiez9Gzh/8YxEXxht+PMoRC6Ad2ztP8CCJjipkFO6oLTGgAuu92qg2YZ4Te5WsAXiH0v ubSMQkqBFUx5wETdwopSGFmN/XT10PY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RumVHh5T; spf=pass (imf02.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-50e7abe4be4so2563615e87.2 for ; Mon, 08 Jan 2024 10:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704739063; x=1705343863; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=/Fn/vm7iOQ6ScVuyrdABBMSC9h+mKMI7gV8fitPzaT0=; b=RumVHh5TAdaYsa3vEb3lKq8nF72scQ6daeOtE12QFCBZzAaj1vsHyKdXwdR4sVNTVR RHRt1Cy1g2TZXMoeaSU6VptA1Q9ZiZf46OvshiGkHc0JCWQHAPWBgEgFg09vMcay9hSy l7tQ86vFKarpmlVEPplG+Njy1udDEpibxWZXZpqxXFydVJtiEr7BizU1Bpjky/lLMYH+ e1sJCjJv+QuBqyUggcESCMtEcJrN3JOoGFA0CZ8JIZh7wnzrRn1SXac+sbKJyLJF0Q8+ ar9sVg1EYF08nzbF3BecPHq4bxE3FbsH3f3th/gSxe2ap55GsJdHqursWPgpueFTW73V 5DeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704739063; x=1705343863; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/Fn/vm7iOQ6ScVuyrdABBMSC9h+mKMI7gV8fitPzaT0=; b=a415m5xGjLXqg7LpOPkf0jSOATUp/ntuTmbdQpnOQqGA07huDFnKEVzuGXfBHePtVt kWAuCiid53uMfu2327dVo+Undff6iNhS0u8Qp6sxpvqiP7Op6u9Fjdjm0CMzb20BoHqR L+FqvK0q8V1fbGxEQc3TsQbhVEXYDtmEbkFBAS7s9g5Nt5pECF/3bO/fWAzyZeAOOvIy 4kkNQeM5QukNT3HcN36TLMVSF9N5IY1eF14wJNPvYRFKpQNBQ08ssfy2OPglMKMbLDrO cfBE20rYiIBkk8ISY/NNWcBr/lMlneQtSBdhnKoVbQpZQLl+4GfXnNnkGYjm2nOh7fZI x3Iw== X-Gm-Message-State: AOJu0YxL6sN/6rWMKw2WwhbGPV9zdR5GmPSgIAM6s4uwOQ/7QKg+4I72 WHNBqCMfCvjNiabv8ZV5+UU= X-Google-Smtp-Source: AGHT+IEGLO8/Qd7YIUC8gujNcMYCMcdnZkTZmkc3GgD/jscUHJQbHAsP3FLNYWFYyvS+v5EUVzsCaA== X-Received: by 2002:a05:6512:3b95:b0:50e:8158:1fae with SMTP id g21-20020a0565123b9500b0050e81581faemr2116026lfv.99.1704739063208; Mon, 08 Jan 2024 10:37:43 -0800 (PST) Received: from pc636 (host-90-233-199-110.mobileonline.telia.com. [90.233.199.110]) by smtp.gmail.com with ESMTPSA id q25-20020a194319000000b0050e1bfde451sm40878lfa.123.2024.01.08.10.37.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 10:37:42 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 8 Jan 2024 19:37:40 +0100 To: Wen Gu , Hillf Danton Cc: Hillf Danton , Uladzislau Rezki , linux-mm@kvack.org, LKML Subject: Re: [PATCH v3 04/11] mm: vmalloc: Remove global vmap_area_root rb-tree Message-ID: 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> <328501ae-828f-4aa8-baab-833573c010e7@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <328501ae-828f-4aa8-baab-833573c010e7@linux.alibaba.com> X-Stat-Signature: q5f1napehiyhfdskb3f6jk6cccei8cai X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 72F7880003 X-Rspam-User: X-HE-Tag: 1704739065-373471 X-HE-Meta: U2FsdGVkX1+xO1d7fctfQc8IheoMD6vazDflZwnQnq0nkeFRjraANu0Uf9KIiEkPyip4NBEe/TOpsYC6oaPNJo9IeNSLDdbye6X95t90eSr+WINpndOFhJwaALq/MwgYITTCcM4Fb8nUNGzqBO6Ty+aFDtkqybPbC7c6bi9HW0A4BrfWxjU9JPxt2QqHHnGz2HbPQd9/XyYYEu7myp0eUGYaLtANUuMwyqg1d7J64FTqliYxPfUx1QtauLGzc8Nyhoj9/pQabVnYzqNDBgLPiaHSVmfcU96vvcOk2kU/z5h55++nAI2gcd5AGPRyF/M0xW9IGdDvFfNUeDzjd5NBiVIKoWPlLM9M6DyzhFLZHSu/gRPSe7es200Xeb3xLydLQ9wwAZTEtNiWqKEqv44s1T8CoDZGSgcvIdB0vWP1glmjtMyylepJ8Clp88cxBq0HTPQN1t4Imf0ygwicX2rn/iA7GFHiE8+Txz43Jzf6zjrGu0gp14S1MrtjK4FRbLiT20HfrsGuwetzwll7dvUtj6qgmho0n5spGAeHj4vRhfmOyaiCk+Mn3nHPL0EJi0uSToPBPdeTILcLT7aEZyiw61Mojmn4RHY9/sMuO702ktnY/yYjOkYGbhsQikzhvAssIw8xAqEZ4Q5RquepPoM/BHvwEH+9FaGtINCLV3qAb/l2myQDrcrREBl9b0YIPCK4EdeU2ZKgE87Q9k3z9LAWAWAQ1+QX28LOxr04RNs1gu/bK2LUQjmHrwdmssydpfr8ENKHks/z4Sr/JgrS665rC90DANYVioWhFcHj6pPjwnAFLvAtP7bCE4gjNI39TIN+kS13CPMIocuxb2bczV4rVOCXSz/+zPjJgfa2Rr8dFSi/f1hq/GfsUyf5+FJ76/8vvomtJB1cKEB9w55GayzQoJC3p/+Sd1lsqxFFNlUhLSTM3RfM/IX8nDRncBv/0Sko0rhsoqvhimgnTRu/hjj BD+zT/br R8QyLp3yUJ65McM5KyQCY7tnkzIUXTEM6Q4TQqWIPhUSX3hmGwrbZF6T0y8ZNJKe07C7Bol7scQErEVPcZhWUZAQUJXj4aKIKRzxiaRttFo0q2aVEWiSQn4ZyJCsof8SRvqKpI3sQj7BYWtEnuiAP1kbXG5MTblBUjUFQEwnJ0VcgFnCXQPTk1S9v5HYD3G48B8tvcKNIVy2x+WZCu5nXjBDoVwa/pDUelMa3vK8VHgEmBQQYc5L28GxjqjRqY3htAVPSHKfNsoW+O91dcxnx32asYrojOA4YfkhKXj6SfVPoBx8TuS0JkE8gYQRkXcHctqWJdDkJnq36jtZTxI352LnY8es4PKxp9iDyYCMUCya0L9Dam6H47n5iQ6qIa8qtMSLsnvRRMuU+kqx0rqVC1Z/VJtwzoeNgNeDKVAu51t5U3y33Iz7nv4We4+ZG/uLKx+Emfwhsf04MjIe2wyolmM6vAyC1CltX8Ce7EA3nCWs/oOOA1Tc25iKWVA== 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 Mon, Jan 08, 2024 at 03:45:18PM +0800, Wen Gu wrote: > > > 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.. > urezki@pc638:~$ cat locktorture.sh #!/bin/sh # available lock types: spin_lock, rw_lock torture_type=$1 test_time=$2 echo "Start..." modprobe locktorture $torture_type nreaders_stress=0 > /dev/null 2>&1 sleep $test_time rmmod locktorture > /dev/null 2>&1 echo "Done." urezki@pc638:~$ Out: # sudo ./locktorture.sh rw_lock 30 [12107.327566] Writes: Total: 53304415 Max/Min: 1620715/3225 ??? Fail: 0 [12107.327898] spin_lock-torture: lock_torture_stats is stopping [12107.328192] Writes: Total: 53304415 Max/Min: 1620715/3225 ??? Fail: 0 [12107.328368] spin_lock-torture:--- End of test: SUCCESS: acq_writer_lim=0 bind_readers=0-63 bind_writers=0-63 call_rcu_chains=0 long_hold=100 nested_locks=0 nreaders_stress=0 nwriters_stress=128 onoff_holdoff=0 onoff_interval=0 rt_boost=2 rt_boost_factor=50 shuffle_interval=3 shutdown_secs=0 stat_interval=60 stutter=5 verbose=1 writer_fifo=0 # sudo ./locktorture.sh spin_lock 30 [12051.968992] Writes: Total: 47843400 Max/Min: 1335320/5942 ??? Fail: 0 [12051.969236] spin_lock-torture: lock_torture_stats is stopping [12051.969507] Writes: Total: 47843400 Max/Min: 1335320/5942 ??? Fail: 0 [12051.969813] spin_lock-torture:--- End of test: SUCCESS: acq_writer_lim=0 bind_readers=0-63 bind_writers=0-63 call_rcu_chains=0 long_hold=100 nested_locks=0 nreaders_stress=0 nwriters_stress=128 onoff_holdoff=0 onoff_interval=0 rt_boost=2 rt_boost_factor=50 shuffle_interval=3 shutdown_secs=0 stat_interval=60 stutter=5 verbose=1 writer_fifo=0 I do not see a big difference between spin_lock and rw_lock. In fact the locktorture.ko test shows that a spin_lock is slightly worse but it might be something that i could miss or is not accurate enough in this test. When it comes to vmap test-suite and the difference between rw_lock and spin_lock. I have not spend much time figuring out the difference. >From the first glance it can be that a cache-miss rate is higher when switch to rw_lock or rw-lock requires more atomics. -- Uladzislau Rezki