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 EB21CC7618A for ; Mon, 20 Mar 2023 08:32:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85EE26B007D; Mon, 20 Mar 2023 04:32:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80E366B007E; Mon, 20 Mar 2023 04:32:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D6196B0080; Mon, 20 Mar 2023 04:32:12 -0400 (EDT) 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 5E4D96B007D for ; Mon, 20 Mar 2023 04:32:12 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2B36BAAB42 for ; Mon, 20 Mar 2023 08:32:12 +0000 (UTC) X-FDA: 80588609304.28.E5CF93E Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf27.hostedemail.com (Postfix) with ESMTP id 420BC4001A for ; Mon, 20 Mar 2023 08:32:10 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=pTWZAvY4; spf=pass (imf27.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.47 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=1679301130; 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=TrGv5DT0Ag5SZMgMITF+1GfmHM3Pk+pDc++Su3UY6Ak=; b=aW5O+JP+BFdg7XHEFyJd3HYCuD2ztoOv+kx2YIiG+GOgV61Uo3B4lWLKr9Taf+c42ep7o5 X163jk3IQDH8BbpzJpulmthtvOjEF7XEHvcpEab+ppgUWnAXH1wcQarvsJOD4KyNWA8r50 2BD8zn82ZjMmc2pHLsUdA1oF9HabaaI= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=pTWZAvY4; spf=pass (imf27.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679301130; a=rsa-sha256; cv=none; b=KvoH2eLRTLNpWtNusPmm4mwbpIXdogd0lECvrLgc0Rq1iLnkp0k8LwoYDPAZ+yvyI81H/E /OsSeUh+SBWVH7L0jqn5FCWPJ4xE2lGRSPc/U33nUx7HfJ3y57Jjp3HC1i0PCTrygNOVPo vGBfbsEfWnq6Vqco93hvst345NrNixk= Received: by mail-ed1-f47.google.com with SMTP id o12so43404737edb.9 for ; Mon, 20 Mar 2023 01:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679301129; 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=TrGv5DT0Ag5SZMgMITF+1GfmHM3Pk+pDc++Su3UY6Ak=; b=pTWZAvY4uc+/eEcTW/0+LqSAViEldvmWs1+v+TPIWgbSsepef9D5ity0cR7lXPAUIM RlP5/PYQ8+161zYZmeFYfzp+65PqA2Eg49cE0MJsXuSJMXTfkWifW7tHA9FGZ2YoKGrr KyRIFH2gmVxMOgHD4JO4xUkZBtGIj1tkijrmZSixewR7VpEfqt+wa9ekBd6iROEzpbpu 2jEdV+H6wLrywuwLeHfSkLLEh0ceDjAFodsNu+1frCAZxUgmiEP7lT60A4LMjEHuGPjx a6K2eRD3+Ui6iGuUnEXCcwP8+0ulnCLQxeDCY/h83/zTkpL0tpFSlKpE+rRuhqguYTZQ MQYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679301129; 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=TrGv5DT0Ag5SZMgMITF+1GfmHM3Pk+pDc++Su3UY6Ak=; b=t9ZYS61T7AW9kAS09lESHg2oMLWS9NHpXl/ALGlcRdhF0FJAvPq6W9qzPleqqdCWP0 q4me7yMmIuAvaewoFY6Z5ZmVpsRfO/Dj4sdyD3rudIkTbSiXRC8J6ilFsvwSVQTxZbnY NoWcpl7QoKQuXiOb8j97g1pfctlA9X42NVSao9PXa40qa6ymMZpPIYPtsotBu7ZTDLEU 21hirFo32O1sezETRqFeo4FkMc8jl5Vx2/7YCs/GZU9Pt+J10UuGcvPRZJ2eU9pTtXb5 /BRlou4i1KeaV46FLdbxB1m1gJf9avt2Oe1V0i7g+4N6GsFOaErj4lIxQtQ1WLGs5pUz 8xeQ== X-Gm-Message-State: AO0yUKXiNUDtMivYNzj4iilETcMCfGj2pSQBXOiJ5GSydkxXtzxQ/Kyi RU9tM/SHL69tkqdPUkxaEpA= X-Google-Smtp-Source: AK7set9mNT0m/vSSnoAco0K4ZODYgkekhFl8OhFeixl4oqMgSwkDkeQHkfi1lufYlqimMjwghXfMAQ== X-Received: by 2002:aa7:c151:0:b0:4fa:c04f:66c9 with SMTP id r17-20020aa7c151000000b004fac04f66c9mr10882319edp.2.1679301128773; Mon, 20 Mar 2023 01:32:08 -0700 (PDT) Received: from pc636 ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id b44-20020a509f2f000000b004c09527d62dsm4495334edf.30.2023.03.20.01.32.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Mar 2023 01:32:08 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 20 Mar 2023 09:32:06 +0100 To: Lorenzo Stoakes Cc: Uladzislau Rezki , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Andrew Morton , Baoquan He , 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> <413e0dfe-5a68-4cd9-9036-bed741e4cd22@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413e0dfe-5a68-4cd9-9036-bed741e4cd22@lucifer.local> X-Rspamd-Queue-Id: 420BC4001A X-Stat-Signature: 81bpkuic5eq67ca9buri6ztu5kpot6w8 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1679301130-458362 X-HE-Meta: U2FsdGVkX19CE2Y6z/y22TYusKlUt2of4dqQl1v4IFzzQLB8pOPZ7ujxWRPwhl0/BWsU5V5fGvum6ZtRGatiANlr08UddtA9Tj+Sw/hNQaQvUSnMKQJ+ebIePwMSsQ+hFDhHubhR6cqwUFH2vmL2NYYpxwU3M/aBJ18/VAy0e/vGv8nqELesHqyKx6mN0RkGXn6+rLWNzidS7FRC9+q189s1CF9PpttHNgPG73De2HWewH+GAOOpAqPc6JBRvK6BDEH06rd2XIJ313X/U7k3OX8U/tK+8fPG4/00rAYKqyvbWFop26aXUBweHq93ZpPWCmX3L9mwWJf7TIA7K/DlIcbFItcs3VVy7srWxd/LoSgYL5kgQ6U8+PlZy+Ff5HC+q9p/DS+2Hdci47Vtyd3itIdbSthA1ZJ054ib1vayfJQvcJeKFQ3s7b8iVQTPQYDY3hJhfCbxvDLDi4Wb+MNSPb3Cs2+yzvDv0F+vslEe+ns65pU41GEDRha5t/HEWNgv2yWgDMtJ2cFdL+TMBtc75rOQ1qP8mvWcM9zvnOBv56qiLN1drfApSnAh7nul0sINbAdaXeN2tkCVVlGo1W6Z9SHvbAKg1f+Dkwb7nm9oKomGN4gvjKkb/4jwwwyHxRjRr91Ye9EhwasdWX2vgAUkyGiWrwbCUKicBVSpFJcMvMXwLOb0+yTmXlVC/fk9Wl731Ai0t3Y/HRS7GBE53f7lGwJ43nGtijPQkAL2TfEW8b9RTnrzImtPJstQn0GZkhN1Y2P0KxOdyzxqcAdo67qko6hBBwug2pQhp21b1s768dpA0FV7buO7purXCFRlp/CChAwH66d3mk7l4bF8aEgjl3hIAfDlEde50FDNwznbY1Kl8Q2y2t5/3GHDkJdxrRCpuJ51j4ya/vpl1avQ9NZDKXd9OyD+IiRH9Yt2o814q3kFRrWQzfAhlfzgLs/7D3Xa9VnfgoiaGvOU/WG9KPS M5lWcbSR 0BffIXvNZIjNB8r2vBWvhH5YyyNri7HeAyoz+jryfMcHilSnKtXoDb03/P8wASXXzbkzTlAFWE/UzmIcZ3hwNNyFhDap2jyo017aC3MKVcFjXuwEoZTqdTPAmwFc8MWwSDi9cV8nWAWBDTET2SYbC6HAFP7OVJp+o0crwgW7auok+2f3bl4/OPLabwLN3/Evz5wzv5VYXjSOYET3gp7SU2LhdGnOE1qdp2IPOeuqXJgk9AV+RfWfNDLLzqjJVZ1VKjFzEHWJY1sgwwp5ZpDArvWMhS+xjDkiUXtW6Prb99ZD/yF4nmXLxPMFFExg+X/8GIX7+8xRTvaIYN+Ge+QEoc0f7lbRy56BkhXgOCHvEMmH7/dA6yw/+ztlNFv7SOC6DgHSABCgHnimNIfYuLSSMKMyjj9MdCSpmKLT5LWpDtGDKhnmtxh8eAYgQkdQG/CCEwCIMnQNHFnjVNpRe6j5UVAjIqslXKTxCs/3aysB5w4eV0/I= 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 Mon, Mar 20, 2023 at 08:25:32AM +0000, Lorenzo Stoakes wrote: > On Mon, Mar 20, 2023 at 08:54:33AM +0100, Uladzislau Rezki 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. > > > > > How important to have many simultaneous users of vread()? I do not see a > > big reason to switch into mutexes due to performance impact and making it > > less atomic. > > It's less about simultaneous users of vread() and more about being able to write > direct to user memory rather than via a bounce buffer and not hold a spinlock > over possible page faults. > > The performance impact is barely above noise (I got fairly widely varying > results), so I don't think it's really much of a cost at all. I can't imagine > there are many users critically dependent on a sub-single digit % reduction in > speed in vmalloc() allocation. > > As I was saying to Willy, the code is already not atomic, or rather needs rework > to become atomic-safe (there are a smattering of might_sleep()'s throughout) > > However, given your objection alongside Willy's, let me examine Willy's > suggestion that we instead of doing this, prefault the user memory in advance of > the vread call. > Just a quick perf tests shows regression around 6%. 10 workers test_mask is 31: # default [ 140.349731] All test took worker0=485061693537 cycles [ 140.386065] All test took worker1=486504572954 cycles [ 140.418452] All test took worker2=467204082542 cycles [ 140.435895] All test took worker3=512591010219 cycles [ 140.458316] All test took worker4=448583324125 cycles [ 140.494244] All test took worker5=501018129647 cycles [ 140.518144] All test took worker6=516224787767 cycles [ 140.535472] All test took worker7=442025617137 cycles [ 140.558249] All test took worker8=503337286539 cycles [ 140.590571] All test took worker9=494369561574 cycles # patch [ 144.464916] All test took worker0=530373399067 cycles [ 144.492904] All test took worker1=522641540924 cycles [ 144.528999] All test took worker2=529711158267 cycles [ 144.552963] All test took worker3=527389011775 cycles [ 144.592951] All test took worker4=529583252449 cycles [ 144.610286] All test took worker5=523605706016 cycles [ 144.627690] All test took worker6=531494777011 cycles [ 144.653046] All test took worker7=527150114726 cycles [ 144.669818] All test took worker8=526599712235 cycles [ 144.693428] All test took worker9=526057490851 cycles > > > > So, how important for you to have this change? > > > > Personally, always very important :) > This is good. Personal opinion always wins :) -- Uladzislau Rezki