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 29B79EB64DE for ; Tue, 10 Sep 2024 04:23:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B33A78D0014; Tue, 10 Sep 2024 00:23:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AE3D88D000E; Tue, 10 Sep 2024 00:23:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9ABD08D0014; Tue, 10 Sep 2024 00:23:12 -0400 (EDT) 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 7C44D8D000E for ; Tue, 10 Sep 2024 00:23:12 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 21BEB40903 for ; Tue, 10 Sep 2024 04:23:12 +0000 (UTC) X-FDA: 82547533824.26.26F4B3A Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) by imf23.hostedemail.com (Postfix) with ESMTP id 56688140017 for ; Tue, 10 Sep 2024 04:23:10 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=W3x5XrMp; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725942163; 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=sOlH/5Y6M5gsktynthjS1eeW0QO1O+aCfqMMFXmDc9I=; b=8GAKdMh4IBsQVOoBnSA2XLJTsvmsGpzgWfvUSIbUDj5AGGfL2GArVxXSj3UcPpFO4ESmm/ v/EKMMD7lmroEdXscxrLTQzfufoVElXLjRewIQfQ3Ca1Yzf22L9PYHZLVmcW68u5BnC/Nf 5nyTv/4cwswfuDVBJiQ5Vk3spX91N9g= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=W3x5XrMp; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725942163; a=rsa-sha256; cv=none; b=7E+JeJP+cSQvRTVLpVSKIesWOwsfO2j38m5riAv97ZRkody5V2IY8VZGMH602UsyMLDSiq YRDXOm42/8jk3rxoByGLuLHg1rmkGp/J/bspeig60uxoperjESIYE4nccFnEYNNxrBc3Pz I6P6/WzG5g2QyjiejB6Hb3dzjOwimt4= Received: by mail-ua1-f47.google.com with SMTP id a1e0cc1a2514c-846d1ba933eso1130827241.2 for ; Mon, 09 Sep 2024 21:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725942189; x=1726546989; 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=sOlH/5Y6M5gsktynthjS1eeW0QO1O+aCfqMMFXmDc9I=; b=W3x5XrMpz16KV2eE3rAdrkFgpqB3asSKBg3XmhLsNBS31ieG++H7iQWHB7YpzQ8LsZ IM9RMkEYWXjH4qEm9tPKtFDGFgM6Ehs/BV7+egYaR6ZdilZ5Ajw3z6N0o4t/SNR4H9X+ vcTm9QHpeSjWa8YZZ/mLHwtUTr0jYqkfxM88VMiIjMM2vQ+7UoGjcJ6dNAUNNeWn1DC8 Ag7j3b2vJhxWli6Z5/yUvZnf6y/1KaTUakm/ACbqxLvyHqQMfNI2Gbb+ATo4tkKZ/45Q CCuMVCJFSkU6eUqHq3Q54gbZQSCKZGpQJRSzKDWFbg4o8wVFeF8lDDufkkWI1zPPjRZS GgNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725942189; x=1726546989; 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=sOlH/5Y6M5gsktynthjS1eeW0QO1O+aCfqMMFXmDc9I=; b=Vl+XVYA5yn0OKtipsA7ZOFNj53+pbKMs/5OGEvUNqc+VaKalSbal+z5p5uti1igUNa 9+hCjUsVVP/vYBuIX0uB9BYsNstfyB2IpeLyQyzdY9E8G690sNvOWZdUMzLO5Lu7iSYo 3d/lgK6jua85HpfQ+g8rpwdsNOOXDj6zOn1XwzhgrsEcWLC8YVha1eYBQ0kKNCfjyc1v CbsFb04+QhQ+0/t8TIKd37xXVwuQ/bDhX2lJ5Ol313wMXybJvkXiqnb6KNpJ898mxgvA VA4iqaDTpQhfUi/UdwlmPYxIaSl2D4EfpCHpTCth6JAg49Z3/UIoGcvoSRzK6hqIpyfq Qe0w== X-Forwarded-Encrypted: i=1; AJvYcCW/4oW9lsSVuREm8ux0LvJ6Yglzdi7EhY23N2ddgyVt/zraJB0B5Cn7HRTCMtwdK5NlRu2cot1j3w==@kvack.org X-Gm-Message-State: AOJu0YzvZJY7SyppKZ5c4sFrdqbaYTRXJSy4h/alif1w/xcCxS/H1GAE YyD++tqh25dcPvMCkLb4155fMyb9ghRPv7akwWqUvc8ZgiADSmJKsuFsYlndQPAnVYsIRZs6EzR hL4QKQJm20gfeXCfutfytoHK3mW4= X-Google-Smtp-Source: AGHT+IHBfJE65bVIUFZvrv6B8kWV68SwZD1l4mxUkUBrgzNMnQicKN/5HK2hynKCnQAMYdKF8mj7GzmFGG5Sq5KVU3s= X-Received: by 2002:a05:6102:358a:b0:493:c767:3fe2 with SMTP id ada2fe7eead31-49bde0f8f48mr10038718137.1.1725942189307; Mon, 09 Sep 2024 21:23:09 -0700 (PDT) MIME-Version: 1.0 References: <20240805153639.1057-1-justinjiang@vivo.com> <20240805153639.1057-3-justinjiang@vivo.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 10 Sep 2024 16:22:54 +1200 Message-ID: Subject: Re: [PATCH v3 2/2] mm: tlb: add tlb swap entries batch async release To: zhiguojiang Cc: David Hildenbrand , 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-Rspam-User: X-Stat-Signature: yczuiwebzg16n8365zezq1cosou3i631 X-Rspamd-Queue-Id: 56688140017 X-Rspamd-Server: rspam11 X-HE-Tag: 1725942190-797118 X-HE-Meta: U2FsdGVkX19sDEGHbUtU9Q4ttLKFPvskJ55bZIJzNHcEa2UjR+cwRilVkvD/wGx0rS9YwUFD/RFaSqtsbU0yoVLaCLMXXN8VDet0gjHfEDxCu6ttqVbBKAREcF+XzwCBAV7eSOQORwEoCCLZbEniAMVEMIc6r6nds3xmw1FZgjt8ExHE1NxUpDZlHYHjw2U9rAO+q0ZM3xk/OAQk+54yDpbEBLbCC8DagJ5jBazruRQGMuWEd+xDuIXO8oZ25YxlD3Ql381TzCdbiaN231Xorj50rpXT2U10FHFw8g9+YPOdNdjfPyT6q6WL8MsjHTHTVQMOl2ALDFKZ8WyamCV9BQ1ke5M8Imc+C82xtmbDyIF+7W/a7oHYPSnJCXJJBYX9zVhsAsXKn1NYNBg/Y7mFYQugUo6EJupoOEfEVwBCNZGMdAaA9NGfIRWSGAk+QtgCTB/JaEy4rbG8u9P7mNmdiK0H0xmNJszXe/QQdblByDVQi9FADMzhJLyg2PI+GZnGWJpQ1gJDKJx8sfAnWaIi81QlE96tUJSYCnMh+7WfBXfFfsGDkOlUDGKDlXFGMNwNFk3LTPllEsEbo/70hFQxta5rAghfmqcfPajZtxmxqBkRWNxty+hn7nVM6o/BxDSyWnLH+DTLBgrYOKdR9ciqPG27mJHo7orPgrYivgUfXk8vOVvaCcChJuGjEbxkiHMNTzRdXXmoPRqxhxYHZ7sv0d9GVW6fx9Yo8aeHh/dXHKYdATH62x6161gxFkRRVodgduSnWf59OLyndZsJb0kqRPNZWLKG9K1bdrqj/MPAXqX4hGLOBfzljOwVgyN2BUxmmBcAjkSSBUGz/CaIxMYWujqxgM9snh5Qn5mOUBFCOxNhGG8h3Vjj3Oi3ZcMzb47GNfffVZBg+ls9qf0oRfeTg74/WdUyKQ7d+3LTrrlXtPNFT8uWJKgYAt2UctZgSNpRF4/WXLp6Hk/BuGxain2 91QQ5/JA 49A3HjfDKuJX+kMWSAYPIYRiMjARLFzQAzHvrIU09DRxaL4Xgd1Fb6vhxrjHqA7OKtf1889qRhTna0sJ7ZH71RjgEPBjyaJUhIbU8Q7Ne5+FObrGSnVaGz/vemyMuQAVhib4Ktxj4lSLgMVFnlHgf8tBn5Lql8Z6/Dygc9PIS2gZ50mfgeSILHMwONTWJOvYdcEGkFO4GZbjQxIduiDRlEbD3H3VLenMmxtYlhw7x4/REUSXLcZfLKlt+4Wgtqs1D67jYIyvsAUE59UW/mh+lDxywiObetKKCUpOi0gEaAbMvKSYqdroHRDHkKAIBbMPwmIDuQ7ccil1waIPXOk85Kfesfg== 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, Sep 10, 2024 at 2:44=E2=80=AFAM zhiguojiang = wrote: > > > > =E5=9C=A8 2024/9/9 14:49, David Hildenbrand =E5=86=99=E9=81=93: > > On 05.08.24 17:36, Zhiguo Jiang wrote: > >> One of the main reasons for the prolonged exit of the process with > >> independent mm is the time-consuming release of its swap entries. > >> The proportion of swap memory occupied by the process increases over > >> time due to high memory pressure triggering to reclaim anonymous folio > >> into swapspace, e.g., in Android devices, we found this proportion can > >> reach 60% or more after a period of time. Additionally, the relatively > >> lengthy path for releasing swap entries further contributes to the > >> longer time required to release swap entries. > >> > >> Testing Platform: 8GB RAM > >> Testing procedure: > >> After booting up, start 15 processes first, and then observe the > >> physical memory size occupied by the last launched process at differen= t > >> time points. > >> Example: The process launched last: com.qiyi.video > >> | memory type | 0min | 1min | 5min | 10min | 15min | > >> ------------------------------------------------------------------- > >> | VmRSS(KB) | 453832 | 252300 | 204364 | 199944 | 199748 | > >> | RssAnon(KB) | 247348 | 99296 | 71268 | 67808 | 67660 | > >> | RssFile(KB) | 205536 | 152020 | 132144 | 131184 | 131136 | > >> | RssShmem(KB) | 1048 | 984 | 952 | 952 | 952 | > >> | VmSwap(KB) | 202692 | 334852 | 362880 | 366340 | 366488 | > >> | Swap ratio(%) | 30.87% | 57.03% | 63.97% | 64.69% | 64.72% | > >> Note: min - minute. > >> > >> When there are multiple processes with independent mm and the high > >> memory pressure in system, if the large memory required process is > >> launched at this time, system will is likely to trigger the > >> instantaneous > >> killing of many processes with independent mm. Due to multiple exiting > >> processes occupying multiple CPU core resources for concurrent > >> execution, > >> leading to some issues such as the current non-exiting and important > >> processes lagging. > >> > >> To solve this problem, we have introduced the multiple exiting process > >> asynchronous swap entries release mechanism, which isolates and caches > >> swap entries occupied by multiple exiting processes, and hands them ov= er > >> to an asynchronous kworker to complete the release. This allows the > >> exiting processes to complete quickly and release CPU resources. We ha= ve > >> validated this modification on the Android products and achieved the > >> expected benefits. > >> > >> Testing Platform: 8GB RAM > >> Testing procedure: > >> After restarting the machine, start 15 app processes first, and then > >> start the camera app processes, we monitor the cold start and preview > >> time datas of the camera app processes. > >> > >> Test datas of camera processes cold start time (unit: millisecond): > >> | seq | 1 | 2 | 3 | 4 | 5 | 6 | average | > >> | before | 1498 | 1476 | 1741 | 1337 | 1367 | 1655 | 1512 | > >> | after | 1396 | 1107 | 1136 | 1178 | 1071 | 1339 | 1204 | > >> > >> Test datas of camera processes preview time (unit: millisecond): > >> | seq | 1 | 2 | 3 | 4 | 5 | 6 | average | > >> | before | 267 | 402 | 504 | 513 | 161 | 265 | 352 | > >> | after | 188 | 223 | 301 | 203 | 162 | 154 | 205 | > >> > >> Base on the average of the six sets of test datas above, we can see th= at > >> the benefit datas of the modified patch: > >> 1. The cold start time of camera app processes has reduced by about 20= %. > >> 2. The preview time of camera app processes has reduced by about 42%. > >> > >> It offers several benefits: > >> 1. Alleviate the high system cpu loading caused by multiple exiting > >> processes running simultaneously. > >> 2. Reduce lock competition in swap entry free path by an asynchronous > >> kworker instead of multiple exiting processes parallel execution. > >> 3. Release pte_present memory occupied by exiting processes more > >> efficiently. > >> > >> Signed-off-by: Zhiguo Jiang > >> --- > >> arch/s390/include/asm/tlb.h | 8 + > >> include/asm-generic/tlb.h | 44 ++++++ > >> include/linux/mm_types.h | 58 +++++++ > >> mm/memory.c | 3 +- > >> mm/mmu_gather.c | 296 ++++++++++++++++++++++++++++++++++= ++ > >> 5 files changed, 408 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h > >> index e95b2c8081eb..3f681f63390f > >> --- a/arch/s390/include/asm/tlb.h > >> +++ b/arch/s390/include/asm/tlb.h > >> @@ -28,6 +28,8 @@ static inline bool __tlb_remove_page_size(struct > >> mmu_gather *tlb, > >> struct page *page, bool delay_rmap, int page_size); > >> static inline bool __tlb_remove_folio_pages(struct mmu_gather *tlb, > >> struct page *page, unsigned int nr_pages, bool delay_rmap); > >> +static inline bool __tlb_remove_swap_entries(struct mmu_gather *tlb, > >> + swp_entry_t entry, int nr); > > > > > > The problem I am having is that swap entries don't have any > > intersection with the TLB. It sounds like we're squeezing something > > into an existing concept (MMU gather) that just doesn't belong in there= . > I referred to the mechanism of batch release in tlb, and perhaps a new > structure needs to be created to implement this feature. We already use swap_slots_cache to collect multiple swap entries and free them in batches. Would it be better to incorporate our new logic there? might be much less change and don't need to touch zap_pte_range() ? for example, while slot_c= aches are almost full, wake up the async thread to free? Or, do you think that cache->free_lock is also a contended lock? > > Thanks > Zhiguo > Thanks Barry