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 A7B01C38142 for ; Wed, 18 Jan 2023 01:20:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D11E56B0072; Tue, 17 Jan 2023 20:20:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C9A966B0075; Tue, 17 Jan 2023 20:20:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AED7E6B0078; Tue, 17 Jan 2023 20:20:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 977626B0072 for ; Tue, 17 Jan 2023 20:20:01 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 726EB40515 for ; Wed, 18 Jan 2023 01:20:01 +0000 (UTC) X-FDA: 80366163402.22.9419133 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf16.hostedemail.com (Postfix) with ESMTP id E5259180004 for ; Wed, 18 Jan 2023 01:19:58 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Px76etJt; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674004798; 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=JXWFfS4aiyJcUPRd+ryee/bpyv1wIIuVm8HjnFM4YwU=; b=Iv56wG1qPIFJx9KwH7VsoORe99Ta6kroKtH1tAMUDV5C/JP+U2BHguztTeTjLc4kMM/97P vdrvP3/tpqyVvfC2WVhDX6sOyn7gyko1cQkMsWnAlDUZGrsTtQ9yslr1+4y+n8ENgDlkAP gx6bDveyTV3j1dRq4nNgt5WGL57Rlw4= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Px76etJt; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674004798; a=rsa-sha256; cv=none; b=jB217PwcnfrYnqEO05tJ9M4SGWucEXtFqvoOQ31zCD7WeEXzQytB2ntqsBsuQHU2TATPlX ByyYypMRgt0koO77PevJMUoX2r5sTKOJQhOT8m1OJoWtcPfNgVJ8Pgsp6ki1051eMQ2Cut 3HMpnA9WBANAxoNRgCuh01SWTJrVe5s= Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-4c131bede4bso448094587b3.5 for ; Tue, 17 Jan 2023 17:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JXWFfS4aiyJcUPRd+ryee/bpyv1wIIuVm8HjnFM4YwU=; b=Px76etJtqo+vzkJY5k26UOhb6WDYZwrowUwMIothVbfItA611chAfKe1cZZbCYe18v pWUOMkcFzisLL0UjLaeC38Vc9PdYHX+FX9AkzPAIJIhgrpwsvPVhbVFn0veZqmzECQNx X2BdlNyIyKIuzT2YeQCjVFDL8FE/Px/uceIbST/a1pV7aGbsLQCPDpebAGoJMjSuOLWv SKIu71ReD/rafQACFoXcYwdxqjH3PldndZq0ZsWTh9tgYpIH5Ip+0a0UN0bLIZhXeYPf HFNTn/s/dz5HXxIDO+CufvyshmF9uyF9zYjoFxKQAKHhdN7hU0pJIUOPsqK1VZhIER13 SQtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JXWFfS4aiyJcUPRd+ryee/bpyv1wIIuVm8HjnFM4YwU=; b=tlMSjtbW+YAN5dzL71B/8X5Nlt6gOjn48NWJXVG+Ug3aQx2/vYG6IQTQoYyzddk/MR RbTY8Fis/ZaodSYTGYbCmHUQWzvz1Y4lru6MjEb7EBFauvaZSgQs8U/PMv/Bu9iIYItK sP0EZ4UGjCDe5iEqOLgXbpXm/SFvjS2rqMulJpqDhvbNQrVBw3q8rX4616WC67zIzr9L UABy1JvLhfGOAKkIe7576QU7rx7a3WXrcdXvUQP8YC/huIpqwwrtgRDmlofTBeJ4XtuN MfU8HMA0DvLEw3If11A2BR35BY63RCpoi7I7EsrpGuYpntTmCHEndZzeXX5MCeZsCWnW TKUA== X-Gm-Message-State: AFqh2krMH7UNCFrPF3/HcGrxXWBXYNgT4gjgJVo8Hny9QtvmnlaJbn86 1tmb0a+P51pdJ4yQeueTj1vPx7dfeMkAYYmwoMvnnA== X-Google-Smtp-Source: AMrXdXuusAXlckmOHYo/FB3BTugnLiciDCWeH/OH9DYwge23YcEvOJoTVCiUAgQM3zYMQEArpfk5YvktjC1zXfSXUx0= X-Received: by 2002:a0d:fc05:0:b0:3ea:454d:d1ef with SMTP id m5-20020a0dfc05000000b003ea454dd1efmr676859ywf.409.1674004797702; Tue, 17 Jan 2023 17:19:57 -0800 (PST) MIME-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-40-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 17 Jan 2023 17:19:46 -0800 Message-ID: Subject: Re: [PATCH 39/41] kernel/fork: throttle call_rcu() calls in vm_area_free To: Michal Hocko Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E5259180004 X-Stat-Signature: kj5eyimxdbp4r79nib365becap5wg17f X-HE-Tag: 1674004798-347802 X-HE-Meta: U2FsdGVkX18nUTgI5julcbDyBcHPi7cGRDFSzfkjLkRvGsyTsBPjxsxb/7n2bD1NqWN5SaY5XRFNpFbtlaHkCt8a36bD1A0NaKga7B2XsAH+taN4BbS96Dr5x7kAMNcwSVtd3UPYFufzjSX6Fkwurf+6W2yGr82taUZx2PbhKoNef8Vsxq60ZkXEtFVOcwzgn1/jvMbIAi2rnAN/+WcnthnVtXTnuxYUWxzdCDtCYrMRz7j2lePYwtbq6Nw6KUC3Hb4cNNNdd7mgBH0lXVWO+0V0K+5Eu8lJ2qOHLr+GN2WuDrJcCLyCWzjpQ7YXSjeyGUEztKL1H+zq/HvmXl5WfeINeAB0Zo0z67N0f2Wp8SBBg+Xen3euI9mXMTSpI+88rJnLcynvcC0fgKBUyOAEZvPGbQBO+tlB2W2WeOBAHhScTMamh4eVyrwJbmswzTq7NvZnLl/8jFF7RmOBPMH5RF/vSQbK9RzqQ74AqKPIH1ODhQHUSfdqOb2RSHb4FzbFsUoAR4KN9YQ4tS08219qS7VSeGPzboe0ROZMwfQUxwZtdWeddgDI0ieTGjAbhnRPii8h5GOnEt82Gem99cQ6V0rstRVyPcZo78eNtqSmRz7NEfh8FB2vyaAYbNZbChDJRxHsEwBWbHWgwJld7RoItqXL7cvh3K8KQoCBM733rPloP5bYcO4Bv7dzrR3kiptaOfXD7TO8XRekcN5qBWrddvzt+isj2p2dDGUQoMhQ7PG1WuhRZRSF7PBPComTostXb77Xi2JRNHMDUBamDbnCVLgwlayYY2NMAMFPPKO5oe27G/W8pavNdOS3bTbc8mDOPSFhX4aV5DOTdJwTWWIgBErqwDN0Eziah5SOh2OFtLC8H96ORH/PxKatq7+9gAmGHpwFQtLGtiO0wDA9lI6CdiOszvwvzntzOqXv404Wkyw5emT2+pl24krFwYm3QHyC X-Bogosity: Ham, tests=bogofilter, spamicity=0.000022, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jan 17, 2023 at 7:57 AM Michal Hocko wrote: > > On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote: > > call_rcu() can take a long time when callback offloading is enabled. > > Its use in the vm_area_free can cause regressions in the exit path when > > multiple VMAs are being freed. > > What kind of regressions. > > > To minimize that impact, place VMAs into > > a list and free them in groups using one call_rcu() call per group. > > Please add some data to justify this additional complexity. Sorry, should have done that in the first place. A 4.3% regression was noticed when running execl test from unixbench suite. spawn test also showed 1.6% regression. Profiling revealed that vma freeing was taking longer due to call_rcu() which is slow when RCU callback offloading is enabled. I asked Paul McKenney and he explained to me that because the callbacks are offloaded to some other kthread, possibly running on some other CPU, it is necessary to use explicit locking. Locking on a per-call_rcu() basis would result in excessive contention during callback flooding. So, by batching call_rcu() work we cut that overhead and reduce this lock contention. > -- > Michal Hocko > SUSE Labs