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 CE940C3DA49 for ; Wed, 31 Jul 2024 02:19:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DC896B008A; Tue, 30 Jul 2024 22:19:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28CF26B008C; Tue, 30 Jul 2024 22:19:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17BCE6B0092; Tue, 30 Jul 2024 22:19:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EDEB16B008A for ; Tue, 30 Jul 2024 22:19:05 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9A2921C06BE for ; Wed, 31 Jul 2024 02:19:05 +0000 (UTC) X-FDA: 82398440250.02.C02A97D Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by imf16.hostedemail.com (Postfix) with ESMTP id D9E68180002 for ; Wed, 31 Jul 2024 02:19:03 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LuhDotYi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.50 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722392282; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EuTTBgp92FvKs6e3kX5RBQcJaA1lmI6qmSNZuE7MUYw=; b=TLaXoOO2uRuPf9HVd4x7Q/95dbqZNjHF4goLP81YF+cRxCoEdEmsGxzGxeisgTWwlWaNBg VM6qlG6a4L075NT7w56x1BQ5zgfkGZ+7xO0r/2JicTBVsiqT2CKpRGCc0VjoXPer56IoUB UbOXPYDsGeOZdCp1UCxjjoI/4+tCmjg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722392282; a=rsa-sha256; cv=none; b=qIEJf4NXh1eD2z/mTk+wD7HHGCreNhgM6uM+yQT2Dm9saaW/NZNY5uF3+jz1j54dwaDDSY iCgNxdTRMsV/xubJuaOMioRjjIs4sVoWpq05tlCKGQvJwb9vgfpTnG1B3KFsQ37dMF2a9N gCPerrvRQD/9MR2nEiK174WVKkh0z0w= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LuhDotYi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.50 as permitted sender) smtp.mailfrom=21cnbao@gmail.com Received: by mail-vs1-f50.google.com with SMTP id ada2fe7eead31-4928989e272so1326577137.2 for ; Tue, 30 Jul 2024 19:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722392343; x=1722997143; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EuTTBgp92FvKs6e3kX5RBQcJaA1lmI6qmSNZuE7MUYw=; b=LuhDotYi1CenC1XxqZBeFePhV68RGqlqGB0oHqgsWR1x1O69tOuxxd6OMXJZHKfRZl 0OkL44sc1/UXixQirU8GI55mwN6RT242oF0YeAakAlx8OY6eemZGELkH7twHR4IuzmcM TdI4z4vVQT9NyimIKcEkQHrzKcT8z/3WqmEMfxH4NFt1Hf4CTHxNmx1JRYmje1fKCOAI l/EIZAeq8qSrCXQ0pIHbH7RykPV93eQwsv96TyvH87GnyUW823hWUcPbBxoGuG06u8uQ 0praFIKnngGRcyk2Huow9LnULzgCdPjDGS9vHlpsnpyFuHxGJvxznLuOd287/Tel5s1W enig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722392343; x=1722997143; h=content-transfer-encoding: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=EuTTBgp92FvKs6e3kX5RBQcJaA1lmI6qmSNZuE7MUYw=; b=URqaBCeqGb5KmsVF3Cn4a3ev8MJCTcTI1RSI6VsumJpvOleUfZ6OjcGKXt6A/L5MVz 3gzPsBSJ3XYRZYwACKHszqH/lIfQQbsIMQKJzOuvk/KGvVT1hQz/g8nVx0TEOm4bnTGt ejASgTl45vmHOa//kF4t7ZZOwYXdqUBr2zt0/1Ua1beXZJ2xxcml9qb6Begohf71XrEv 9cxopgpWr3PK2a1x2wGaFt52U265Le7KTizXza41LPGcszLicxb6VtgjG2wcSFd1vixh XyKfI8U8CCWt356Ue2ASCVCFt0WfhJQ9a0sWm/+TlPadQ/ICImlJJi/YBl6YrB8N3Vp3 9oOQ== X-Forwarded-Encrypted: i=1; AJvYcCWWP/JAkrjqru0WZNgGq1c4lPfhKomv8H7iASnyR+Tr1/JBfLeyRCAiK+7sgVz0bGsUrfufYpIidVMye7TRl7Mq5rU= X-Gm-Message-State: AOJu0YxCaiQUZPt/FpvAdRCyawKiUZPnTa31LEObIHMhJtZ3whAvR9oc 2ZuUwk5tgM9brMguAPVPaQeWtRMsTKDcrgkRnPes4/FPonFXp6UwDE9iL6bCDceK8O741/E9vZp Eo6+xpDgojQAL0YCT7EpdhJTB35w= X-Google-Smtp-Source: AGHT+IET32HsRUmh5QkmUwiju7XuwyuRfEv3IIhJFoZqlfnE3LGBqWMtNG5FTioR1NG2RfcEAUn/nvMGw2OZ8dW8FGQ= X-Received: by 2002:a05:6102:2909:b0:493:badb:74ef with SMTP id ada2fe7eead31-493fad48fdcmr13920389137.26.1722392342815; Tue, 30 Jul 2024 19:19:02 -0700 (PDT) MIME-Version: 1.0 References: <20240730114426.511-1-justinjiang@vivo.com> In-Reply-To: <20240730114426.511-1-justinjiang@vivo.com> From: Barry Song <21cnbao@gmail.com> Date: Wed, 31 Jul 2024 10:18:49 +0800 Message-ID: Subject: Re: [PATCH 0/2] mm: tlb swap entries batch async release To: Zhiguo Jiang Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Arnd Bergmann , Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , linux-arch@vger.kernel.org, cgroups@vger.kernel.org, opensource.kernel@vivo.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D9E68180002 X-Stat-Signature: te1899ua7jrbu3t15c18xawc933pffr9 X-Rspam-User: X-HE-Tag: 1722392343-935951 X-HE-Meta: U2FsdGVkX1+OJOq9p2KymrvDj+USQs6jo+tv6+xl5BQ9LxrL/BOucO47qqQll/mVfIxQEgADLVC1cswMFHR3D3lrCxKKeEfKH2GxbCpE2OQImh26r1W7rc7knaz41UFHs4SeEJG2FTiVHrDY8of/wwRJhMUL7BkCUSV9W2yPKXNDav1d4Vjs7Sz3HbIO3oxObrDx8hiSpkquEk/NoA2/2ELO/E/ea7AnM33H59RQFF/4NIMTaMU89S++DALosKsBJs1bPQVgEvvt6PFtPFpRusFbfzBck7T/Etd59hA+MLdnoQFB0v9oUNTFOCuFZmQ127MqwjPoQ9zVnrBIQg1cU983wHYVnTDPoUPFYduHMJvvX8zPzvALGc/uOTpxhhzxLA+0MAxQbWLRTN8R1saqVsQC5vVPiHZrp/MuFIXDFvt3wwcDu20ELFKAQ2vO9B3arGdmBtyLDY21VfWjFcOgCjFmW9SgPba0bRTQPcML30MYu3EcvuTRrjdvPWXC/2oQU+mleDimhX2SzUtzYV1InHaCPMWDIHAQnP52JolJRien3XnRvl9L3gKdWGaVqOjn9GN5AFf6qgOkGQj2qtDqgKcANciyOjPtvYYNoLJvZWjmDUzkSJw4a37BG8/wpARwyEf2PL+y4Ed7VJL6eIYvljCqrvvVUiNM0DS4pXtA4RAsROcB4tRrxy4Klzz15vYTdzl8s6Dv9eCRSWThNvApNd3lOXWUvrBBmSJx79J4swz55Qbmpmg1/c3/lOZeRcb8Cz4c6KJBsBeT1UICxZDwfZsUZwZMZO8kP/EjdoP8t0uzXhce7kcaG3j+QrpIKAoeQ0b/EyTJI/lbzGOdaO0R8jQxQsbVtEOSvCOWgpm0t3F8hadGlbInWf2bzzMk7Kp4HPF/4uUAOYym9fPdsEn7YqaM5feWeq82KzwAsethd127M0fc91eT5jlF+Rln5+TqjQZmaI2AngZX77X929U YE1nKZxi gewwCcCMZdzsGytHG/rxb4ez4T1eyqZt6jd3S8nnZeVeYL21h9SJTREFXobcFSBRCTjf+yJhjyA9/JXauv2zCV4xhESXfVeLZpAZeEt9W1LsxwaWZW45OzW/k/QQdxxXkK49im0Powf11XcPkZ5t99W27WbcT6BnlSjbyhit7Ovni9yAiapF56Yeak1qifm2rADU7p4YPR4JJ+rH1V8WyYZ3CutD/I3lf08dICi60qFcQGDYEVWWrH8QaSz6orZ7RQ/3ZKLyWMdFLhUDZPPKz/wIE0v5AUbmB+aQ52QCp9eGWS+hzYJBBzrFv8aF8RGG+T+9JWOmZU5O0Ij3n1wHptWuXkYXcVolzVz8Ghlh1NYBoRL4uolVSIc94T50k8AsNMAQOuJwBpVjapjI= 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: List-Subscribe: List-Unsubscribe: On Tue, Jul 30, 2024 at 7:44=E2=80=AFPM Zhiguo Jiang = wrote: > > The main reasons for the prolonged exit of a background process is the > time-consuming release of its swap entries. The proportion of swap memory > occupied by the background process increases with its duration in the > background, and after a period of time, this value can reach 60% or more. Do you know the reason? Could they be contending for a cluster lock or something? Is there any perf data or flamegraph available here? > Additionally, the relatively lengthy path for releasing swap entries > further contributes to the longer time required for the background proces= s > to release its swap entries. > > In the multiple background applications scenario, when launching a large > memory application such as a camera, system may enter a low memory state, > which will triggers the killing of multiple background processes at the > same time. Due to multiple exiting processes occupying multiple CPUs for > concurrent execution, the current foreground application's CPU resources > are tight and may cause issues such as lagging. > > To solve this problem, we have introduced the multiple exiting process > asynchronous swap memory release mechanism, which isolates and caches > swap entries occupied by multiple exit processes, and hands them over > to an asynchronous kworker to complete the release. This allows the > exiting processes to complete quickly and release CPU resources. We have > validated this modification on the products and achieved the expected > benefits. > > It offers several benefits: > 1. Alleviate the high system cpu load caused by multiple exiting > processes running simultaneously. > 2. Reduce lock competition in swap entry free path by an asynchronous Do you have data on which lock is affected? Could it be a cluster lock? > kworker instead of multiple exiting processes parallel execution. > 3. Release memory occupied by exiting processes more efficiently. > > Zhiguo Jiang (2): > mm: move task_is_dying to h headfile > mm: tlb: multiple exiting processes's swap entries async release > > include/asm-generic/tlb.h | 50 +++++++ > include/linux/mm_types.h | 58 ++++++++ > include/linux/oom.h | 6 + > mm/memcontrol.c | 6 - > mm/memory.c | 3 +- > mm/mmu_gather.c | 297 ++++++++++++++++++++++++++++++++++++++ > 6 files changed, 413 insertions(+), 7 deletions(-) > mode change 100644 =3D> 100755 include/asm-generic/tlb.h > mode change 100644 =3D> 100755 include/linux/mm_types.h > mode change 100644 =3D> 100755 include/linux/oom.h > mode change 100644 =3D> 100755 mm/memcontrol.c > mode change 100644 =3D> 100755 mm/memory.c > mode change 100644 =3D> 100755 mm/mmu_gather.c Can you check your local filesystem to determine why you're running the chmod command? > > -- > 2.39.0 > Thanks Barry