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 8C2C1C32793 for ; Wed, 18 Jan 2023 18:04:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1451D6B0072; Wed, 18 Jan 2023 13:04:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CFDF6B0075; Wed, 18 Jan 2023 13:04:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8A206B007B; Wed, 18 Jan 2023 13:04:55 -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 D9A276B0072 for ; Wed, 18 Jan 2023 13:04:55 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A703940595 for ; Wed, 18 Jan 2023 18:04:55 +0000 (UTC) X-FDA: 80368695750.09.E82214E Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf01.hostedemail.com (Postfix) with ESMTP id B0DAF40029 for ; Wed, 18 Jan 2023 18:04:52 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Mtf8L2D1; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674065092; 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=ZmeatwLvsnhfsfO1/vmX5h6tsP0MwkkpxTHRWfYdQM4=; b=a2XP7mmn6rMmr5bPMvYV6s3Gni24zP3F4H3lyueNa4hBRdmikNaRCJmdTnqtoYX1BXBj/F xgp0rIyOYyRkJYPfhrAGbZFnzQCc27PkZI9RUFPiSmjAOPBtWzF8dgG/i+9xB0IlJw5w3u dXGP3bR3rGAyOrvAJdK1pSDwUxeZf2s= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Mtf8L2D1; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674065092; a=rsa-sha256; cv=none; b=TQbhgzxEnH89TrBaBqxX5eXEPcvoDQ/FPH1jrhXhrk3liRQ0/ANZVW8+ECEsXZ4HtUYq+j YbUxEOM8OkVsVVfUquZBIVA2H37JshGYt8rSt+ReAX/RUuWG8/DK8ay8+xRgyGICSdrTWI cJ5lp83xbFk+Qbgt779jb7ssquPNO1c= Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-4e4a6af2d99so160247767b3.4 for ; Wed, 18 Jan 2023 10:04:52 -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=ZmeatwLvsnhfsfO1/vmX5h6tsP0MwkkpxTHRWfYdQM4=; b=Mtf8L2D1PhgJlzWzwjotEfjVuKX38JU222q+auWI4G2j0q5YtHekYj771Dhkp2GcsL HDhNkGKRpjAR+kjPXD7ERMmqZqi6tMxaQHWTECXnzcywWm8J//b3A6EagHn7DlypEpQ4 Cpw58T97xq7K+rLqSTF5aaSGBUwZ6tOQyaE+127JgHNle7jNMu0hs4a0nG/uwPZbXmRI xT5pUt95Wwx7KFEi+Hay8anthmFFMsA8dAo2cnCBZvoiTur1bsXgUihQ3rAI4pZO/ZWP hbf2HdqSN+DbKwD2nFd64CgzevmW3m1IqCuzwC7PQduRR0Dz80K3WPLTv1MB5R1OaZsr XF+w== 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=ZmeatwLvsnhfsfO1/vmX5h6tsP0MwkkpxTHRWfYdQM4=; b=N/Z5meqqG8NrpKk/fuJxHuC8HkbhzwJuN9nJ/Csx4DxSJvzYLLhaS41dAOhxYNzM5P KF5mHmMeqzavgIIvqiLHcZEVpxvAT2XYIYtar/n+TZI4LBLLYxKxK8bxiqo3jWq0Z+4I 2NcK501C9eWkeESI4qZiUS7St2w9oqctCLI3WlahbBqFtqp/D8dyZAGXaJ/TgDuQSVWa OiZZ6CAeLeP4wbGwm4P9FmPImLTzc7C282XVgZeANg4YGYPCb3sH2YnrTdj/yg/DPkVb CotsRDnAqCEU0AGV1LgPam3w71adssBMjORIe63L0oOwxhbzFCuDCn25KMamgAZRyICA kNLQ== X-Gm-Message-State: AFqh2kqGJtjhmsZ5hSmXHiyMchr14qr5ie3mfFTJAoQA4wbhPzCbb0m4 oBX9iYrw3KQj8q1eAlaydCTfGHWdjert3Z64mJb9/w== X-Google-Smtp-Source: AMrXdXtMjwBQUdURBBz5ZgKZXjOXMVezYNYkyKU4WLD7CgzuxYNgtvI+JEVCsSBPA66t4nGGBzfjSicrSeLDwN7bPco= X-Received: by 2002:a81:6d8d:0:b0:490:89c3:21b0 with SMTP id i135-20020a816d8d000000b0049089c321b0mr1031972ywc.132.1674065091255; Wed, 18 Jan 2023 10:04:51 -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: Wed, 18 Jan 2023 10:04:39 -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-Stat-Signature: mhcerm1u8der3ucm9twzrd88qz347jnp X-Rspam-User: X-Rspamd-Queue-Id: B0DAF40029 X-Rspamd-Server: rspam06 X-HE-Tag: 1674065092-288966 X-HE-Meta: U2FsdGVkX1/dNS8l5KaJYcivE5aEjNEAe2YKNKwln9a+fZUGrTXxlj5buh43Fbv39laY0VBNREh9oyt1cb2WmK8Uu0g1fuXUzEzsrMTOfmii9CnePAQlZjtVlbrpAfEPbzWBqcffHzOUa1Etg3mPtqV6ZLS02Eo/SEsq4d+r0rL9knizqS7YXkdtEYeKoewiDT0UVfdMSgVop2jq0DqPWF5BWoIgSvTNC4S099KVGVLbCr1WaIbAbRUjd46bEuxjMQHWulKn8dCm7AQDnHPiVDY4TtWBQ5Pk3FiBJ+TQ9XeOj2d0TmPBPKwJcbEy8JGk8OO7J1xfvWKfc9lk03v7MI45kY+GNs9Wdr2zUteayQscbo1eruznwkboPtqNbcTyucx86t3oloHUOaBTsVDfTFkuRUNDhBTdnV8PXYuepg4iDe3SFiE3N7nCHFVcBFsNMrULY2mUn3Xtsx6Pvtca728PAsw+alPoULRTDi7pftOVy9kq3LRjkKW7YsWqWXeIvreoLwH7kKLiqlkhzF94wBw4qUsCQE7oMP9OgE6GnuGpYFefzHNtDjuxzFG4VtM+SCRQE8rtAFiLLwVr4m8924N21rgRDI62/y0btRIntvYNckqh/+Xb1zKXeoABgvN0zQ+DC5QGA32awmdYNsgSWfgMC+aDL7yOmBsL56btKNL22olDClvr9XO2ruYmfuFqAhHNXE7x7pEf5aGQVXwaDEejrHNhMRHlSeyzogHNYTu7T2jYSWR1O3NNjtfts9rb6XE8SlNcn1YGt8ewgMveP5SzjSD3TnT00tVfef9gbzJ/SLY2uzFuxfgkkFVEee7RfFI8Iqc6ndLOhMniz1g1u+GZy4XDS5kYAFOhYo/rZZnwz4sRfWFGmup1mYw9ln3Vo7Wqx+cvQ4DvcvaL3C0O4wZq3JcxSAGenP7427qTuqFAg2RBWeZPbvseasqIYxa8JNlR1ICRepUL3SPUoHr XUQKEyFq gVsTejDJPPDJ0gtcSvVTlcNoECGkgKzI0A9kKX3aLhRcGnt1TOe4lX0crng== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jan 18, 2023 at 1:49 AM Michal Hocko wrote: > > On Tue 17-01-23 17:19:46, Suren Baghdasaryan wrote: > > 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. > > Could you be more specific? vma freeing is async with the RCU so how > come this has resulted in a regression? Is there any heavy > rcu_synchronize in the exec path? That would be an interesting > information. No, there is no heavy rcu_synchronize() or any other additional synchronous load in the exit path. It's the call_rcu() which can block the caller if CONFIG_RCU_NOCB_CPU is enabled and there are lots of other call_rcu()'s going on in parallel. Note that call_rcu() calls rcu_nocb_try_bypass() if CONFIG_RCU_NOCB_CPU is enabled and profiling revealed that this function was taking multiple ms (don't recall the actual number, sorry). Paul's explanation implied that this happens due to contention on the locks taken in this function. For more in-depth details I'll have to ask Paul for help :) This code is quite complex and I don't know all the details of RCU implementation. > -- > Michal Hocko > SUSE Labs