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 275DEC6FD1F for ; Sun, 19 Mar 2023 20:31:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82D516B0075; Sun, 19 Mar 2023 16:31:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DD0A6B0078; Sun, 19 Mar 2023 16:31:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A4156B007B; Sun, 19 Mar 2023 16:31:31 -0400 (EDT) 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 572CA6B0075 for ; Sun, 19 Mar 2023 16:31:31 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0FD3AC0162 for ; Sun, 19 Mar 2023 20:31:31 +0000 (UTC) X-FDA: 80586793182.28.8CAA628 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf06.hostedemail.com (Postfix) with ESMTP id 31719180013 for ; Sun, 19 Mar 2023 20:31:28 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=XH3XjdmF; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=lstoakes@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=1679257889; 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=7cFhYBMM/sGGl7pUJxalvtsHlN8hIIUBXY4TsO/Ulp4=; b=NCnDmrqMNQVrNTOYIJ54J5SRclNVj/tocabO9OxAJBYrZdBlEf9u2FIociWTi5cq92uWs1 773tT0ysvWBWhGAN/zq9elU3gaJta47hgNvVL0/apHPJ58rqJ3jJz9QOPPqtabZ8ApWXS+ TpSTFEgjPZvjHgCl2W0oW+jp4enJfPk= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=XH3XjdmF; spf=pass (imf06.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=lstoakes@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679257889; a=rsa-sha256; cv=none; b=e9hZKJqSQ1gRP+sb+OZnTbezgSK01yWnXbpqZZ6LRBYJdwJeeI0jifmoh5hBlXMFagFDFs tA75y0hlrli51WLVzcrRT1mxbOnFFxJddm/VZWh5rpzMVNrsrIdnzMw+jliy4HhdKmOZui qlupECukkAzhlvJQb7shmIPj8JZzwe4= Received: by mail-wr1-f42.google.com with SMTP id y14so8608989wrq.4 for ; Sun, 19 Mar 2023 13:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679257887; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7cFhYBMM/sGGl7pUJxalvtsHlN8hIIUBXY4TsO/Ulp4=; b=XH3XjdmF6NLQPjyVOunH3smTe6tOJwpuub27ZPlebc1ahBFynKOYZC0MdcMSmQEfn4 M5k4G8A8SShX1sW08OKDlIBCfKKnBYI5+lvpa3tmuyylE4NDDuVyZierz6SUo9xPYClv nlHMBk8/1j6eaS0HfiLSuIa4Ra3SHWBhlaZ1CxPa3OEaoG6Lea+k506s5uRTxF3bhG8i mvIFGWP7dRCP3B4Pp8HlogCXAKy+4/uG1i0MQC2fYVCVcHySCDKscNnz/2hHrQ90JYxn lFaQSyS5LkR6t2h5uWuOUsfIJKP09DRJNcPnYlLjnGrju4TkEcXgqVbyFTfaj4nqlNbd ONSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679257887; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7cFhYBMM/sGGl7pUJxalvtsHlN8hIIUBXY4TsO/Ulp4=; b=iqThzSI6jtpjiItGr66Yg9M1STHhaFPfpcXpxhtDahiuvYdJdL9hRXPm6C6IXEVyPA FyyodhDvsvEOIxi9R4pY82nOMakfl/8/DYIalzg7dbnnxrv5CLg0mXTS8LdOoOUEheRX 6qOzS4fMNsyAXL/2Gh3O8K82XxGa+wcgK0OoUaYlXntzdoq5zYISsvv0RMsfBE6JZYox ow+nreYRYjVDrTQGafsmVZdlPrOxF6OGAYKBl0KwLd8HMr++/TV0G4AGNKmFWC1AKlyP 4opg/ABvVyKT2mdjkXRvjQ32mXvWzlRURiMz2zppUJP0G2Jkp4+TSMd5yB4tUBlWuxX3 kKrA== X-Gm-Message-State: AO0yUKUA32cFCaYI95KgG4lzXebeC5biXPTG0UIgIYf/lwbxOlsXV0/y NdPBdTI1+r3Ce1hTqzYZQ4k= X-Google-Smtp-Source: AK7set+pIJNGSG5LeaQdnKFzjoOJYJs+d1dlSBU2X1SCQGdjp/5s4IuGlPSsXl6L36T0AdB/QjJ2QA== X-Received: by 2002:a5d:4848:0:b0:2d2:471f:cf6e with SMTP id n8-20020a5d4848000000b002d2471fcf6emr9074119wrs.5.1679257887423; Sun, 19 Mar 2023 13:31:27 -0700 (PDT) Received: from localhost (host86-146-209-214.range86-146.btcentralplus.com. [86.146.209.214]) by smtp.gmail.com with ESMTPSA id a4-20020adffb84000000b002d322b9a7f5sm7248708wrr.88.2023.03.19.13.31.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Mar 2023 13:31:26 -0700 (PDT) Date: Sun, 19 Mar 2023 20:29:16 +0000 From: Lorenzo Stoakes To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Baoquan He , Uladzislau Rezki , Matthew Wilcox , David Hildenbrand , Liu Shixin , Jiri Olsa Subject: Re: [PATCH v2 2/4] mm: vmalloc: use rwsem, mutex for vmap_area_lock and vmap_block->lock Message-ID: References: <6c7f1ac0aeb55faaa46a09108d3999e4595870d9.1679209395.git.lstoakes@gmail.com> <20230319131047.174fa4e29cabe4371b298ed0@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230319131047.174fa4e29cabe4371b298ed0@linux-foundation.org> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: m56j4egzz91q89as9ixcotozmng4p9mz X-Rspamd-Queue-Id: 31719180013 X-HE-Tag: 1679257888-142150 X-HE-Meta: U2FsdGVkX1/vpbS6t0WmnckIfas50ZEccSmx7n4pvytTJEg7kKcPigxgU3v/yz2X8ddAgYt72/v76ESgUzqtUXYNQQhjgPWhLgbAZxIMCuScxtGnynkkdrrd8LScjxJsgvIK1O1CUgYVTlZ34B8yo6HV5hawaYa3g7z5qKavy66TCha24Laa1DGHvSz4jrLQ0htLqt9MYga/1KP8T1e5tGn5wn+cPBXyk/7L/S4PuTNMY+/8zegxI1TSRfgjDhuKrP6GC7FJrNAKnK/9SFeGYVF9x3RBg4Lk/2dTYhrkrODQjaO44w1VbmPcLP4JZ/PR7P9+TKOdBWkm+NllnZOtnMWBnVdlUlZ8gDNJ+c0rqS+m9sJXt16oM5TzXUPtVklGbIVCyuox10O8JKXogoBBEPo0TyJll2mLZrAK12InHFt4ipGLeoZHug5G3TTutO/r2YQxxzmSFSgSQl7Asxnq7IKRzuA+SH5PMVLSNQ45jHm9N1kqzoZ+kcLSnsBiog6PP5KQmbMj7+mORbBICL0R+6I8fYmVYuLty7M50lbKKIGVIPVywkoGT47mHYcjjY4L5qUVWJCi5nvBUp/H2CiDzwf6PDGxyPE5xXbU3ziBZgq6JhBsWDlDHQFNsyx8N3tj0hSYuOkqGsLicnJXYLEba5KcPrMh9g277l1vauvysq7zCLZ6M0O3GMkY2yGn3/1pMyO+VPZrl4XNC26epT9KyA4R1yehII/31N9qFAmrmZoGFfB4zCxaVujpuZFfQU0uSlpRsLQD3B0K/NKvZAchJA2K63o6I6+l5x3Luh9qAhej3ECiR6jTPbT0D1o/otqSI9EVhWTRIYVQ9OJSTqwYvgOVBg2fnSCkys/HyAtR9Q+hjA4GZR4CBYfo3IZgSU9PzTzEugsgy+iwSbf9auH9ynaZ6y+QMGv5Iy4OURLzPd6toC9QnyP/vLRj5Pjyf71ABmqKQVQfaSJiGU2yr/+ GVcEnVAN cyiB1UO5fefnULqTv9u7WsE0N8GtfzgJMOVxg8ySMwNUYDU+fMWHq4t5h01SiQeo76hf/pJaN3sZy+wEnDHkUPIxM3kp8zEMIKQmeqhcO47szkT4RMjNx1Gyv0iLMg5RQBBqQD0lQZ4ACsllfJm4+oZImhbl3Ccuj6QPaBnzHDnJmLVGe76UyxADeKpeSjxJS+CLKJuaLH3VIQZwp6dhCQLWDcz5RtBi1QlkaHyCOYPX415cNAH1WPhCwMzHLOSGvgsZZtbz5UUP3YSQLTm6h/mPLkV/h7n2RyhAqIl73kgO/vj2HAVju32SU4rrcMHlgpvit+XPmjmA448WYZDnhsT1cNsJ4JIP4dz8vieQB+iEcEH9+khIRS6UHQtoe8Pft54kkwuWTWjf4BaopE2nUN+/UP/anBUFhLLJOgM1dE2Hps9itYTI0CP7B1uYjk4YsVL2XjQ/38OWpUpMamZaEjTb0CyNGHUhpb8Ci 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: On Sun, Mar 19, 2023 at 01:10:47PM -0700, Andrew Morton wrote: > On Sun, 19 Mar 2023 07:09:31 +0000 Lorenzo Stoakes wrote: > > > vmalloc() is, by design, not permitted to be used in atomic context and > > already contains components which may sleep, so avoiding spin locks is not > > a problem from the perspective of atomic context. > > > > The global vmap_area_lock is held when the red/black tree rooted in > > vmap_are_root is accessed and thus is rather long-held and under > > potentially high contention. It is likely to be under contention for reads > > rather than write, so replace it with a rwsem. > > > > Each individual vmap_block->lock is likely to be held for less time but > > under low contention, so a mutex is not an outrageous choice here. > > > > A subset of test_vmalloc.sh performance results:- > > > > fix_size_alloc_test 0.40% > > full_fit_alloc_test 2.08% > > long_busy_list_alloc_test 0.34% > > random_size_alloc_test -0.25% > > random_size_align_alloc_test 0.06% > > ... > > all tests cycles 0.2% > > > > This represents a tiny reduction in performance that sits barely above > > noise. > > > > The reason for making this change is to build a basis for vread() to be > > usable asynchronously, this eliminating the need for a bounce buffer when > > copying data to userland in read_kcore() and allowing that to be converted > > to an iterator form. > > > > I'm not understanding the final paragraph. How and where is vread() > used "asynchronously"? The basis for saying asynchronous was based on Documentation/filesystems/vfs.rst describing read_iter() as 'possibly asynchronous read with iov_iter as destination', and read_iter() is what is (now) invoked when accessing /proc/kcore. However I agree this is vague and it is clearer to refer to the fact that we are now directly writing to user memory and thus wish to avoid spinlocks as we may need to fault in user memory in doing so. Would it be ok for you to go ahead and replace that final paragraph with the below?:- The reason for making this change is to build a basis for vread() to write to user memory directly via an iterator; as a result we may cause page faults during which we must not hold a spinlock. Doing this eliminates the need for a bounce buffer in read_kcore() and thus permits that to be converted to also use an iterator, as a read_iter() handler.