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 A4D75C05027 for ; Fri, 20 Jan 2023 16:20:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 298086B0072; Fri, 20 Jan 2023 11:20:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2483B6B0073; Fri, 20 Jan 2023 11:20:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 110FD6B0074; Fri, 20 Jan 2023 11:20:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id EDBD26B0072 for ; Fri, 20 Jan 2023 11:20:57 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C33041606DA for ; Fri, 20 Jan 2023 16:20:57 +0000 (UTC) X-FDA: 80375691354.10.D4F5B8C Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf22.hostedemail.com (Postfix) with ESMTP id D1949C0019 for ; Fri, 20 Jan 2023 16:20:55 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=a3fpOXPW; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 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=1674231655; 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=mfgPoshwuIu4b/1jDgs3cdlztQz/vsY4EyScZyBxABE=; b=IveNytYGFnh4QZFTTPHoN8WKqfmQxQ2ecSXiHHucQqxTp5HAKtqWUCagmdCR55XQfnuSOF 8xEo8oZQ35Ht6mO4SI6NoTyYxGaQ/hVbKXw94ZmcTUJvlB2AdJXBt/x2p6ROUV3VOJddCs 3w+t5kMOkpL43Q6zZiW0MxrdNAtSgzc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=a3fpOXPW; spf=pass (imf22.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 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=1674231655; a=rsa-sha256; cv=none; b=sOQDsuHCgQ5seYMHkHF3tI22Nn/D45qMwklP6H8baLrRpPMFvogCsHgW/erpddJkBvviT1 q6ZYwctsVbl4P8F4vuZ/15ughQcIr0SJ4AOxHBfT9taUijrrLC4HRsSjhJjjyzCYBXc0o/ BMrzGpBDifMU5qY7y9+Lfc5NlBFyPmA= Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-4ff07dae50dso34081527b3.2 for ; Fri, 20 Jan 2023 08:20:55 -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=mfgPoshwuIu4b/1jDgs3cdlztQz/vsY4EyScZyBxABE=; b=a3fpOXPWNViHSb5VK8vv6GJ9OmjGr4J4zqU4T6ftPkVNCscUsuTtDDXL5UD9ux6sdV C0Qm2jvON+yzeEaRn5EGinE0oa53S+FAHBxJzKLsuFtanPw31pELeAvEJoY/yaBISJcM oZyV2Lj9bVOFMBWicMFpowezChEy/etWrkR++6jVuHqIjnOtt+gvWs/hH0z9I+hVbxLK DdHjJ3jcS58ULiPGvEyZtKwUEI8IP12OcCaoFotUfcap+K1AkIWIglgZwi5rcdiqfHFL rPSSgGWeY5keQ2LWcVC+CM7q02imT0drV8318cIgX8BCEYEkWOEzW/6DbkrmOLaX3cWG 1G+Q== 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=mfgPoshwuIu4b/1jDgs3cdlztQz/vsY4EyScZyBxABE=; b=XtqqMdbga3IkgkfIwy+BPpxeHfSQbbBgKz3pSmm7zzScM3uQIfY8fhApvpwOFeHH8i G3eZnQb1HNcIpczOUKiW7i8pEur0tjRSO9RZ+SmaRNrMIjjH1FktYm1QUlH/BcPYU4rE NXQnuwKtxUNrdkQwTF8VGDyn/xynrIIh0ovajdXTS0SptHusIro+n1vce+/tGrue394H cPai/Tvhp4OSclekRp132yhv4hTfv+NSZdJJV2IcRrufvaMdZaKdLsG6kxxn9JQT3Fac 0jFktv3F4mW2+T5Iu7jvG6jZjSk/PkSPWh+3SyYAqAAKsCNkdVQUzqMKbHKo+RJ3mvZ1 fBAA== X-Gm-Message-State: AFqh2kraQJg2BJ8ag1MDR4DP4yM2j1bTftFkyEgG2jj6HPfrBnk0eL4k nbLQFMTk5ci4iDnZmA6ZAEaFPytfS8753TSuzWbRzg== X-Google-Smtp-Source: AMrXdXvNN5DOlSBxjqhx1vO405B++97EByJYfshx6Ib0y61OUe+J+zmBSfLMkdUumg4HC6CkMKiKUEscqc4n/PQFmVk= X-Received: by 2002:a0d:d484:0:b0:4dc:4113:f224 with SMTP id w126-20020a0dd484000000b004dc4113f224mr2100604ywd.455.1674231654470; Fri, 20 Jan 2023 08:20:54 -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: Fri, 20 Jan 2023 08:20:43 -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-Rspamd-Queue-Id: D1949C0019 X-Stat-Signature: nafq3m9ua9iboyop9phkqdkkfxdjgzyh X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1674231655-344676 X-HE-Meta: U2FsdGVkX18jpgvufVtSkurrRsk7DaF5LDyg120BTcsBI3ec0OSiDxcsZ9RauVGu+8wdjo/tdu9197gRMlB+O4bv3FwFIms7xqDbJNpfuQP+5dDMljOOoJ32uNKnlrnOZVFc5tlQLBx0KaUdUghSXH6nhvhmAfB+QJeJBdmI12AxdEyvkERphNIOXkZ6l1y/RoEV5Y8b1Igi8nDxncMuDVN3sZ+BYhNhlpyTOIZZa9OL0AX1wjpUX5y0ZRB65/yyT8FUlldqfNugkQLHmAjsZ8MQ6LyWGUpb8W39v5MPbi0xGMprdWhONN1x/YI0wVC2Xg7YTT2TM/xkoTXBZoBEJts787tvaZkmqEg3b1wfZCMFRHZ5yy5p55bEcG7QQdhjqztyM006Lxx1BKnkTdPnjsCn+rzJ9KQW/pFXZTwUGRqWqvqz3/pL/eem81diff7obq6S4dmzCMQNU50abt39v9mLP3IwVkJoHMF4rbeyi0KdOyHAN/0/GzjJKHRk8HA91/QjUwT+oWvmySDzX8s5UrCY4b26aVh7rJGUWVlsXJWAHjwlbEjVeXz90S2g+rOcgEvJ6N7RJfKibZgTk75+Z41lTYSA3vucDy8la33YAuMyjCdxp646RvWulHp89TOcJSZwYgJR/D3nTxWqW4JXTIDbj+AtgozjUzx8MuUmGoUR2IQKYxAMdUWQtiJHeVgaauUgoL+ttAvJVU7nMa2BCmFzzMaLllpLt/3A24Y+bKP6B0ECyw5cwG+HwyXwP93UGeORUNlMmhQ79DtoSk6hwPpfcice0zBOpXWdbqeEO416lXNZpDQoxBn0BB3ctn12KX4oVOobhawZp+/d6grQa4OcR0UUgzUvf2SvwJicVsBiAU8hPeEESibB5TUpIPcF+A3kIfZzQObP5M51Ucd0eSFoajLwdBQavqa56IF209dmjHNM9voqH7+Tp+C5x0rYBCgkVYhm1VQq0sz1JZ2 VSdAsXcR PUryuwrLxWD2h1p8J0hPPmgA44dn1AE+jqLvyaNFaWoz5GRNQNNxl/wzTViDtPf35POO6hGNYQsOouBY6vucTye0TvK+yk0oqES52e7D3WOZl1tpcie7TOc1m4nTqwiuFYLTWIguo+wWPKvkfdhyIg25AFuCSx4RyHc/NpBEOFwiqe75P9hcIOPILY5Yzb/Uhg3HbVtZXNTuXm+Uf7myirKPbwM+1zdJoqu5YNB+zSOkzvDAFlu+xFm0lZ3v9LGhZbtzO+ZSYUTrwBULqZuiUaBAIQOcP9AJLGQYrI+d6BnqTS3t+l69It2Il1kEC9zPyzDdA3iZgLHldixaeVIU/0r8rD/vCBrE4VsRE 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 Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote: > > On Thu 19-01-23 10:52:03, Suren Baghdasaryan wrote: > > On Thu, Jan 19, 2023 at 4:59 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. To minimize that impact, place VMAs into > > > > a list and free them in groups using one call_rcu() call per group. > > > > > > After some more clarification I can understand how call_rcu might not be > > > super happy about thousands of callbacks to be invoked and I do agree > > > that this is not really optimal. > > > > > > On the other hand I do not like this solution much either. > > > VM_AREA_FREE_LIST_MAX is arbitrary and it won't really help all that > > > much with processes with a huge number of vmas either. It would still be > > > in housands of callbacks to be scheduled without a good reason. > > > > > > Instead, are there any other cases than remove_vma that need this > > > batching? We could easily just link all the vmas into linked list and > > > use a single call_rcu instead, no? This would both simplify the > > > implementation, remove the scaling issue as well and we do not have to > > > argue whether VM_AREA_FREE_LIST_MAX should be epsilon or epsilon + 1. > > > > Yes, I agree the solution is not stellar. I wanted something simple > > but this is probably too simple. OTOH keeping all dead vm_area_structs > > on the list without hooking up a shrinker (additional complexity) does > > not sound too appealing either. > > I suspect you have missed my idea. I do not really want to keep the list > around or any shrinker. It is dead simple. Collect all vmas in > remove_vma and then call_rcu the whole list at once after the whole list > (be it from exit_mmap or remove_mt). See? Yes, I understood your idea but keeping dead objects until the process exits even when the system is low on memory (no shrinkers attached) seems too wasteful. If we do this I would advocate for attaching a shrinker. > > -- > Michal Hocko > SUSE Labs