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 B4103C46CD2 for ; Sat, 6 Jan 2024 16:36:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD4066B02AE; Sat, 6 Jan 2024 11:36:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A85416B02B0; Sat, 6 Jan 2024 11:36:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94CBE6B02B2; Sat, 6 Jan 2024 11:36:30 -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 837CF6B02AE for ; Sat, 6 Jan 2024 11:36:30 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4271B40495 for ; Sat, 6 Jan 2024 16:36:30 +0000 (UTC) X-FDA: 81649439340.21.4104799 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf19.hostedemail.com (Postfix) with ESMTP id 614C71A0003 for ; Sat, 6 Jan 2024 16:36:28 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CS9vBG65; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704558988; 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=2PkbTEqLvSjOGH4gAdgvm5eYy4RG+4E+lRHHV2QJza4=; b=dyW/nXDVGNi4Ll5j3Ec6uvaZCIOhmY273v2oQBYOn3e66+20TaKssaRUjoTpElIX9fpL50 hV9msENGje+1jHTOp1Wc9XUPR1Jka3bc+O5RZVVVVpkhSAS4BhP4jtt2InovhaELlYOP5s yNvpehQGWdIjbFCiBiuiRbZkGSxI/8s= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CS9vBG65; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704558988; a=rsa-sha256; cv=none; b=bt9i21rMhjVE4b8bcFfD3qGb7KAjF1AvsvrLNWs8bMQFTNfYs/KtSyAlRI5+e8l6phqkUL da0a3e6pbjYKbcfmmj5X8WWUG9HlQI7GCF1Ft6u0lpJdoXNjtHPfVGgtrSOyfAdyG9H2EX qG/XlsToVlBRGhkVQBvBI35cJGWw/+U= Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-50ea9daac4cso513591e87.3 for ; Sat, 06 Jan 2024 08:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704558986; x=1705163786; 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=2PkbTEqLvSjOGH4gAdgvm5eYy4RG+4E+lRHHV2QJza4=; b=CS9vBG65SxGJ6TIdwpLeDp4Y9o0HltpeJQyzw/cxmnSMeB1lxXXPfmK0+QGvkBYnRU +exXuPVCdU2qPRMCipWnaxw19XMW/9IuRpRNtAYzKQTOR4tFbsfKuucRY2ZEerfJJUKK LCaj59zr7MWE9arublLF7+iNRFN1JMyeRHnYhh4BAJ96ysnE9WEp2wRflsbxEyMzZAj0 BOnnAS0o8CL7Xv/fWv4KqEl3OMolPl+/Re6ZS5NVV1lxC1/fxYYKzqLr8VzIRmeOC0G7 3KFtU8FTVCJknrbeoUOJiUcLnGuKL37fi+jkIkPP1Jwh/0Y/+VF65PbmDmv8LrtwJN+s XuKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704558986; x=1705163786; 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=2PkbTEqLvSjOGH4gAdgvm5eYy4RG+4E+lRHHV2QJza4=; b=In9bhIwblL7mA5qH3tEKiypAxu/G9cV7KdwuKueEvSkgchZ580zBRqwd6xhGBD68rd L6Y5BuxuW12iMYMBFYvPbfSBYsyGLeQW9iFT84ZZiBfkoKnnzWK52IPPz18qaZZvy6Cp 6cjfwPiG4mK5Gts9Sd7ceoIB250nHTZvcCmLvT9bQzVzxe4MY1rTkM+ujCezfe6RIMXM LkH9T2iXHnajYMUWgHIrdSQQeIbl44Pr4powNm7NVoN3BZ0u7bpp8wgi52YMaBV8Sw7q CT98joeXu0jqpD3FaG8D273ti05bCJ0BbnsRWFl9qUIXyIs4IfChAv5Xc+nibNK1FF93 0xpA== X-Gm-Message-State: AOJu0YxE+pc90UiJxUa0bUzEZCchRGg7btV+cvG6AHYMz895sYozTMgO bisIwCkEg7ZLNUlJiNeHgB0= X-Google-Smtp-Source: AGHT+IGx58E/aB8XT4+HDN2sbb8Yr4CM8JOoydFTdDzNP6CGkX6RTKDZF4zPDJyYa3KMVmh4U0huNQ== X-Received: by 2002:a05:6512:36d3:b0:50e:7f88:f541 with SMTP id e19-20020a05651236d300b0050e7f88f541mr437850lfs.16.1704558986281; Sat, 06 Jan 2024 08:36:26 -0800 (PST) Received: from pc636 (host-185-121-47-193.sydskane.nu. [185.121.47.193]) by smtp.gmail.com with ESMTPSA id r8-20020ac25f88000000b0050e67d56093sm566500lfe.224.2024.01.06.08.36.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jan 2024 08:36:25 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Sat, 6 Jan 2024 17:36:23 +0100 To: Wen Gu Cc: Uladzislau Rezki , shaozhengchao , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52766da2-41de-41ce-b60b-1118da343b8a@linux.alibaba.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 614C71A0003 X-Stat-Signature: 49fexhgeodbe6hi3ypzgumcits9uwn6u X-HE-Tag: 1704558988-40922 X-HE-Meta: U2FsdGVkX198OmJM/c8g/98iu2eOZLfTUYXzd1Fn7OUQvg3SY2HfFxULV45QU57mVtCRubqvpbl58F+CziFKwGZvDhx4E9U8cI3g1HRDpJMmeBppuki0Go/d0xQohQUzmm1MEEZx0MGKpybhR6Pav7rDmPYqG5rXb0Q+ozvnPtz1GgbkNXeaDTv5rHgbTJuzVb4garVCXrAOOy1L5mnM3x7JV9xcDmODFVB4pphBgtRd5YyaBpar2hoiSO1LhaZb9qGtDxXxFPgHanLAlNSzZGVYqbW/kPZVyRnrdX4x9HE0TVs5XtGTi9/bNl0+EEGWe6Op6VBTQ+6TUcoWU56k9K6dkgkwJFrW31KxQllRQ/ECcYJ32If1MCN3n1FDWzhlEEguKXt5KqFYLHbSqRAjJAaFmBkcQ54NSR6iWQlWkOh8uBgCS0kPuRaqX8irORVFkHw3RRlLkSUMWUys9pfLtu3kAMwu0m2Mk8RFpNSTKQP+Da4DfFmTThA4s5RZRFJQW0BzM2jMLkk4Fiaz7AsmXmURRUGgADkzsSf0TvbwvRtPGJ8rmMMgTYHaw49qiiA8Z/cAu/6OT/OOlo6CTjhPZq/fxhmppF+sDHeVs95ULL0hLF0rKlKT0OwUTDQAT0uJf9Q5rb4Vqo4BXO/cxEnYtA9Ep9kR5IpmQa1PRkPCnIAev2dBzPcRyja6aZP5EeAnHb/6rN5M1rWR4tOv/ZUmIhJsRxG9LPyyMaOO+WF0VlweSfQV2Hso1T7XFUvDOe29Dtqw3Qkdv2Z33ryiqiARYfF93Ur9QAIM1Id+aTt78vmrtPKpeA895dPvd4IA1eFpOhR0Ecg90w8FTkM9eN+lTJhixQP7e6mgcDhAWHFKwIXQQcbBcXFVXgQb3HZ5O6KQZa7DCAWfVwGNMHAY59tJrXr7bxBIbbQpc/YBTnzDHbkYZva5JMyu5XQrZeDHmvb5jGhGdNbr8MTIcrv4OU8 Jli3jwA8 j4b5Ip1ASBUxKr/PIeDJJWW0HvlqSuk7VHGRheaSLW/7Vz1wRLDht6G3OLHTn5tPGTHXGsGqeDAl0VWM1Isr9RszKiY9yrGe5t5v4LwdxaYUflDqGio7+wZdponMrIjb3TAUKb5vww/gE/0LHMxlRYm7ziwx29lBETlnXrFrJ1nXN86WIxpMrgbWINqFegfVTmMZSby98cZPtGaaZzPJ6sZJy/+lY/BggcMB5PO5iOV/cOEOme1y+5HvyJyN8XBTJnbV9H6m6FYeA3S41L3uXLEpHahBFQo+3N+mZcVKS4r09sQBQx2TngzWPuUrQ9EGshbOFNNF3CNRQGSzXKrZeXG40IGKqrefeVh7APjjtuXJdY0p56u+eQTa9jhmwH3S+ujxeMbStHCpCBMo79Y4oV3UQJC1wasx5dPO2A2LJGrfptLj1cVIgOI5OG5nhxZt3W+t/1/eLwYGawau26Hw9Z0IWv8kWgw1e5jT+NzlTq9G99C+2GfAXRn+D9Ta6xP11IJfI7CIm+PVp73E= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000251, 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/5 18:50, Uladzislau Rezki wrote: > > > Hello, Wen Gu. > > > > > > > > Hi Uladzislau Rezki, > > > > > <...> > > > > Fortunately, thank you for this patch set, the global vmap_area_lock was > > > removed and per node lock vn->busy.lock is introduced. it is really helpful: > > > > > > In 48 CPUs qemu environment, the Requests/s increased by 5 times: > > > - nginx > > > - wrk -c 1000 -t 96 -d 30 http://127.0.0.1:80 > > > > > > vzalloced shmem vzalloced shmem(with this patch set) > > > Requests/sec 113536.56 583729.93 > > > > > > > > Thank you for the confirmation that your workload is improved. The "nginx" > > is 5 times better! > > > > Yes, thank you very much for the improvement! > > > > But it also has some overhead, compared to using kzalloced shared memory > > > or unsetting CONFIG_HARDENED_USERCOPY, which won't involve finding vmap area: > > > > > > kzalloced shmem vzalloced shmem(unset CONFIG_HARDENED_USERCOPY) > > > Requests/sec 831950.39 805164.78 > > > > > > > > The CONFIG_HARDENED_USERCOPY prevents coping "wrong" memory regions. That is > > why if it is a vmalloced memory it wants to make sure it is really true, > > if not user-copy is aborted. > > > > So there is an extra work that involves finding a VA associated with an address. > > > > Yes, and lock contention in finding VA is likely to be a performance bottleneck, > which is mitigated a lot by your work. > > > > So, as a newbie in Linux-mm, I would like to ask for some suggestions: > > > > > > Is it possible to further eliminate the overhead caused by lock contention > > > in find_vmap_area() in this scenario (maybe this is asking too much), or the > > > only way out is not setting CONFIG_HARDENED_USERCOPY or not using vzalloced > > > buffer in the situation where cocurrent kernel-userspace-copy happens? > > > > > Could you please try below patch, if it improves this series further? > > Just in case: > > > > 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. -- Uladzislau Rezki