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 A59A6C433EF for ; Sun, 9 Jan 2022 22:59:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A87B96B0071; Sun, 9 Jan 2022 17:59:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A35406B0073; Sun, 9 Jan 2022 17:59:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FD2D6B0074; Sun, 9 Jan 2022 17:59:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) by kanga.kvack.org (Postfix) with ESMTP id 8116F6B0071 for ; Sun, 9 Jan 2022 17:59:54 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 34BAE8CE04 for ; Sun, 9 Jan 2022 22:59:54 +0000 (UTC) X-FDA: 79012267908.20.8C24723 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf23.hostedemail.com (Postfix) with ESMTP id D9E3A140009 for ; Sun, 9 Jan 2022 22:59:53 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id u21so23924517edd.5 for ; Sun, 09 Jan 2022 14:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JichIxBzlu+gabrOqQBbMPOsNHYmhCY/t5tbp7G0B7M=; b=kgHkAD5+T6PvIvnKRVStbR9axj45u0zQZQ5Ajh++vJu5m6K31ArZpk2IN3u29P6Ts8 0Kcj9/w6x1pMK0BkEOzWRIt1AhFmg/UoG6PQg5hESnlGa3qh9bDzv7ekWmnYQqmHVAcA v1v9x7La9ewcyLBOiBqC5yl/V/Zj5lHi7+3j1d6iQbfHVT9uJp/7a1otpbFshIBTKDSh wsRr0V0vkjIP56fu6yCPFayVkLH2+jhcJ0ru+G/qECb57GxGOHDhaqM1ef3pBVGbMhDm 6DsxE9Sjrl4/6Pu+PiVrpzUYePkyzWxI268lzABt4FJvjUTak3G4GAlv2gpd3a0kv7lr oabg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JichIxBzlu+gabrOqQBbMPOsNHYmhCY/t5tbp7G0B7M=; b=H2OP2RP5wkkS1MytWcx+LwXuCP3eb7CnM/I83zvRCFP6gDwp1OfBu77Deda569hlUl x2wy5qm7Ol/YFwC6d+5ZE3cqRsAch6ARAV3EeLV7w4HRE2zUe3vyiaSpuiZRaQWqOveO J0ULU+M+w/gFiHa5RhgobxrW/ItSCDYUlibI404cC+C8CYbTI0O/Yej5Mu5yP4uH4FXm izb/9GyIBaHN18xPWViDEdZ3kJQ6NCWsQtjA4T6nDxS6o5HipvRyaZOzgwpux1uWMNOX zCOJrEXvvNiNnFNAGhrHpC0RvPEQK1u9uGL2Xfme+MjDqQ2cqhTmHLCT9HjrhQRf6qKM T7dA== X-Gm-Message-State: AOAM5326CItqR9CX6Or51kC2V5o3/GnPLooePzRd+cVPrEzBr3AEGzAU 1j/stI3eSyXhE1UCZc2A/vkFxBAbBaAWFVO9g1U= X-Google-Smtp-Source: ABdhPJxNWqr5kmxsLYsT/zArMcv16U9D8HQ6t/tgYp/axFuIl3brCOR+Lnj9TzrscWzwvbef3kkV5mYvAuiVz+llCQk= X-Received: by 2002:aa7:d554:: with SMTP id u20mr73148751edr.322.1641769192522; Sun, 09 Jan 2022 14:59:52 -0800 (PST) MIME-Version: 1.0 References: <20211130201652.2218636d@mail.inbox.lv> <2dc51fc8-f14e-17ed-a8c6-0ec70423bf54@valdikss.org.ru> <20211202135824.33d2421bf5116801cfa2040d@linux-foundation.org> <20211203222710.3f0ba239@mail.inbox.lv> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 10 Jan 2022 11:59:40 +1300 Message-ID: Subject: Re: [PATCH] mm/vmscan: add sysctl knobs for protecting the working set To: Michal Hocko Cc: Alexey Avramov , Vlastimil Babka , Andrew Morton , ValdikSS , Linux-MM , Linux Doc Mailing List , linux-fsdevel@vger.kernel.org, LKML , Jonathan Corbet , mcgrof@kernel.org, Kees Cook , Iurii Zaikin , oleksandr@natalenko.name, kernel@xanmod.org, aros@gmx.com, hakavlad@gmail.com, Yu Zhao , Johannes Weiner Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kgHkAD5+; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Queue-Id: D9E3A140009 X-Stat-Signature: kgm4sjsbyt3uubofn9oqg7b1hjsac1hx X-Rspamd-Server: rspam04 X-HE-Tag: 1641769193-766501 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 Tue, Dec 7, 2021 at 4:51 PM Michal Hocko wrote: > > On Fri 03-12-21 22:27:10, Alexey Avramov wrote: > > >I'd also like to know where that malfunction happens in this case. > > > > User-space processes need to always access shared libraries to work. > > It can be tens or hundreds of megabytes, depending on the type of workload. > > This is a hot cache, which is pushed out and then read leads to thrashing. > > There is no way in the kernel to forbid evicting the minimum file cache. > > This is the problem that the patch solves. And the malfunction is exactly > > that - the inability of the kernel to hold the minimum amount of the > > hottest cache in memory. > > Executable pages are a protected resource already page_check_references. > Shared libraries have more page tables pointing to them so they are more > likely to be referenced and thus kept around. What is the other memory > demand to push those away and cause a trashing? I've heard a lot of complaints that shared libraries can be swapped out and thrashing. it seems page_check_references won't be able to relieve the thrashing for them. on the other hand, exec pages could have a very big mapcount, that means reverse mapping of them will take a lot of time while they are reclaimed, so this makes the user experience even much worse while memory is under high pressure. Are we actually able to make mapcount a factor for memory reclaim in some way? The difficulty might be that a big mapcount doesn't necessarily mean the page is active. for For example, all processes mapping the page might be inactive. but reclaiming pages with a big mapcount has been a big pain as far as i know. Thanks Barry