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 3B8A3C38142 for ; Mon, 23 Jan 2023 17:43:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0FE26B007B; Mon, 23 Jan 2023 12:43:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ABFFC6B0080; Mon, 23 Jan 2023 12:43:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AE9A6B0089; Mon, 23 Jan 2023 12:43:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8C9E76B007B for ; Mon, 23 Jan 2023 12:43:57 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2E3D2C2457 for ; Mon, 23 Jan 2023 17:43:57 +0000 (UTC) X-FDA: 80386786914.24.6DF6ECB Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by imf12.hostedemail.com (Postfix) with ESMTP id 4C5B240006 for ; Mon, 23 Jan 2023 17:43:54 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UKgyvnaq; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.219.170 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=1674495834; 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=MbdRXrDm0G4b0pDa706c1R5MiAQkWSslBdaNrC2lB8E=; b=fZ7Kriv13qRMaI8BtXCzNdIZbIHYyDxnUMZJWRf6t4ahwJ+WmiXG5EG5gkPP0PJlb7bnJC lLB/WYyHOLNKu5vM6jFJbmhzjXmYwihF2vDNxIBNaUDEMMeWDiSb6oSRMcWxArHLR5ITtz eSOHdCXHLZfFqhtFLh+XhN80gS9Hcqo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UKgyvnaq; spf=pass (imf12.hostedemail.com: domain of surenb@google.com designates 209.85.219.170 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=1674495834; a=rsa-sha256; cv=none; b=EllysLwjXbPFV85DHxYWCztHxB/9EnXBlb9dMQSdoi5Gr6Jo/VwCNwqJFQ6Pv0oy1qirh1 +pr0bjh0RoisOzk/3fXfZ0+788OFShzuS5KdpCxiwOSwaUmqIk7L4b6oObOChA0y2NFfyq IO4IjmIAM0/LkuhQCUTVvNQqNRW60WQ= Received: by mail-yb1-f170.google.com with SMTP id 129so11819610ybb.0 for ; Mon, 23 Jan 2023 09:43:54 -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=MbdRXrDm0G4b0pDa706c1R5MiAQkWSslBdaNrC2lB8E=; b=UKgyvnaqxpZWuAuXbcWe7aJn7XDOmRlf6QqbtRqmjjqrNsksyykciJsCGgdpFt2CQN XaM6W9briujGFL1RejiKuJCKUrqcWGECuEv0OBka8AMNnOltN07JzxO9woC07V5MRuOK lIGOuD1tj2+OitLRlkQ9TOXjMyPT3MOwju8jAeSrJY3jOJu7B0x9/0b4Rr46ORcFPUPL 9m5ShhmVH+bnYWtWaCQ9gf7B6SXzpYPqiyo6wDJ1V+8nI9leCdCm54s2S2l3cLlB1Z/A 1s3Xgs5ERx34l8e2oApkBnckWM17ROseI1caWCFSAoNsCQy8/3j2aKxxnE8MsD360zHk 6R6g== 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=MbdRXrDm0G4b0pDa706c1R5MiAQkWSslBdaNrC2lB8E=; b=CNUQ2Q/3C6dlrbJNHYeaMc5mSmRTfPY0dtUQ9LzCW+FO6qh0YvawEW4K8LCvTW7Rac eYMdfygEAxZIggHZhcBVcA23+4EHqH6SxrSbXx9Mw6y99Zhh8ewA5+m3EpBKH/XQPChz LYYEFoK+KPZNMA7ZhoSul79QDz5R6Fz95vZTs5vum42Y+0lw4vus0kzCdoiN1m/qZrG8 CyoWkUwzPujeDLrc7Fyu2vB3lQUnHlZaCOiJcPGMrFrNOCP7lJyb1MAoHD0mpAfkLmch zVc1+MTu3jNcVds7FtNz8TGlPTMLH/D2e2RDYQLX+Q7Gu84nZKMy6rKZZYsW0qPFPWtl IBKw== X-Gm-Message-State: AFqh2ko8t/h7U4ie3by/gxIvSeUMFjzAbbDdWrtywQaEHzBat44HTX0W mcUj941NmKReb+4J01PGh9l2EvyzabAFQihkcbhd5Q== X-Google-Smtp-Source: AMrXdXv3CgHU7SkUBkM9SwlNLny2wsFhjN99Oj3tapcuDlBqTQ5sZwoVRHtRKxpb3b0xJuv4qrd+j5dOi4ahKRGg9aQ= X-Received: by 2002:a25:a408:0:b0:800:28d4:6936 with SMTP id f8-20020a25a408000000b0080028d46936mr1456121ybi.431.1674495833086; Mon, 23 Jan 2023 09:43:53 -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: Mon, 23 Jan 2023 09:43:41 -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: rspam04 X-Rspamd-Queue-Id: 4C5B240006 X-Stat-Signature: cm9fz4z37k6fgejdhfrffrzyxzxp6hps X-HE-Tag: 1674495834-949441 X-HE-Meta: U2FsdGVkX18N34XOQZ11tJ8mFqXso1URcBJq3+Hewv5KZXz0OQbrir8+f98VJeCh/nADHAbwgDq6CcDs/xxjOKcWf4cosJNjt2KzjXpbFqjFfNe7xQxOrBPs+GWz+tlqRwzuAhIPN87J9eruOViaonRAxhaQdhfsmNk1ekKY5QXeWgfk/qjmjjC80zzKhwfjIWGAjCcfokBaK+eefebQN5xHC00/9artGBtMoEmLB49oQJok/cDl1yJHnQwnp2hMGLNLjpYNonC1itvgCp/bVjBn0i6eLdaCHSK7M+zqURUFfpnKfGgYpv661WKFoOQ9BGYCELvgkVIowgOHknOCaPs+VNcjNaPpE6rFBOa0hecJ+5E+GtNRSRJ9QJdLp9xFicv2iBrK9xerUQ2ESNxVcB/2NjOPeiIsKWsSYdNhfZF1ZXLflVoVYbTaLRHm3MCs6xrhflQKJNr8U9/c3xVjFn2hj7PqQqosckV2vUdMqyvZhvhUOaKsxG7gVIxDOQ4BFhmlawBbDRP7HQJvFkpSTDvFvFC4gvin4BLzj/JmOwmLM9HF3N4cIEBF4ilOHikn1toRjg6HpvH9A1dRcZOtIE5Edc5fjuil/B5iU7NDHdbe6PHylFqQ7vTMuV/vR2rboBj46m2rWyWS+STVQYRKpR3WG/iDxbSGrcGRlj5YwgZTSPTXWXk0UzZH1gSyLX8GAVyYHzjpTOzsvZitMjWcbno4tRZqo84EeT7uaxxrUSLHtncqEhsYzC3+DJUPmhcOMJziB+0EkBBVtbGggcM712fjLmUNGzIrLR2aYC2qRR65WXz4cI/C0gCmzJQYFAG2pGD6ijKhFW5yx6/aIJk51fWD6TOK1V1sY85rNmmoiFu7AxPBzYruLoSp2DIl8q/CISYeuhkxpfLkQlDYO+GS6vypsnqopHzGBYp3Lduh8DK+h9XNpCta67HjzbiWVWidfTVL/a1DTRfsxO+DT3x Y2SNDJFv CKSm9zrycQVwxEbbk12SeHvvwLOL6kGQCK+JUd6plXLU5PGWSWwts4kUoO7yF/WFNpOB7yQE4Ri7qQ/6AtVzw7BwJSWgsftmJnkulIchc0aYxS3qoQV/8wW6cCKIh7dcvWfG8f0rW0WhAISgQfXCj6+LVrwL3jeGwjlE438Ow7wFgkd+U8Y5vrAf/wdK7fP0G6VQVCqCAimdIUegvay/OlDgt2tyxxRLgy56mq6Bi7ivx2VSwRBTgLqcD/KLL1VEbVPYY7zIojVShCjJR1mTQ+fXFPiu0hOrm63nPsJ+CBhvPLYyzHIBFjpBBeUmgyGYbjUYJMZvdDEe9La1MxCx2tmY/E+s5NAgn0jHeBZ8Hf1KzoZFlT4LA9vLlVsS9rlIvjFKyQFxC7iGT4DF4vgsY9IbIvg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jan 23, 2023 at 1:59 AM 'Michal Hocko' via kernel-team wrote: > > On Fri 20-01-23 08:20:43, Suren Baghdasaryan wrote: > > 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. > > I am still not sure we are on the same page here. No, vmas shouldn't lay > around un ntil the process exit. I am really suggesting queuing only for > remove_vma paths. You can have a different rcu callback than the one > used for trivial single vma removal paths. Oh, I also missed the remove_mt() part and thought you want to drain the list only in exit_mmap(). I think that's a good option! > > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com. >