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 6A62BC83F23 for ; Thu, 29 Aug 2024 13:36:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C1EFF6B0085; Thu, 29 Aug 2024 09:36:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BCFCE6B0088; Thu, 29 Aug 2024 09:36:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6FE96B0089; Thu, 29 Aug 2024 09:36:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8836E6B0085 for ; Thu, 29 Aug 2024 09:36:27 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 01B0A80E18 for ; Thu, 29 Aug 2024 13:36:26 +0000 (UTC) X-FDA: 82505382414.29.F8E1CD8 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf16.hostedemail.com (Postfix) with ESMTP id DBF3A18001E for ; Thu, 29 Aug 2024 13:36:24 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=U8Eet9OP; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724938540; 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=wwzrWSl4QmNb//4oM3ybSBFzbuQXvWdfQdlCdZCtaZA=; b=R65anLQcWEKVAdj5c0yvoUHjtdotIXsHfTev8FYjvbr1M/Kn8EKk9P24bwyedYT6gX++eU YcNF/yMjfY1d8J7SyNrvgJ7evq2g96WqDEwjw4vRKb6KpXrf3IChGdMl30waDTPxPDVk+g odLh6S/ONsuCzHbfdmNFFWz/PfuX+WY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=U8Eet9OP; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724938540; a=rsa-sha256; cv=none; b=NNtV4UBplkwdxzZGkn+XVPAq9P2Sp77wmd7fateG8VuE7hI268+owKa2CFJr8VNLh9OrhD u39GZl6eMM6b3/l9C+G4l+RMCnPtksLZaIRo6v9pWoQPfIe4mkDHESxO2N6inislBN9Mpl JcTyQYC9muP06VGXiAaaYstqLKK7h5w= Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4280ca0791bso6304315e9.1 for ; Thu, 29 Aug 2024 06:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724938583; x=1725543383; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=wwzrWSl4QmNb//4oM3ybSBFzbuQXvWdfQdlCdZCtaZA=; b=U8Eet9OPFFWnIFcs2bOmu+F2+N+yfK5y2Jr+bbvwRslL6mMy70HKW12ymrhlDDez6A PGTSH+P/u2mzp+6SZe7CDb0V/QDYjCMOWTClN3oX26i59r0ojduj265r7zLLPOHaVMNu dy8xBSfZSql63yF5IP8jWA9vBgGInUjy6SpYE8BziOhMCdBxTu0UBkS1ylynPI7/+kak m51z+Cz3ORYNab+BJ8yVwbhpKFT++XbXSCoC0uopuMWA28e73bO4UT5cSkBUZUELISfH a8vEL9B+95g6bxKStxLuF8ebs3usYmmFUC3l+A2QMTJ3gCS/BgyH6dz2ECeDEolH9a9P 5cLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724938583; x=1725543383; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wwzrWSl4QmNb//4oM3ybSBFzbuQXvWdfQdlCdZCtaZA=; b=d9luqDy25LqvYCHBM9IHiqoqDvuEk2clNifZ9m3ZyVQ3yrrhYKioFKO+W+JFW0l1XO 1F6//QCG3E+8Etg7dNuFTT6/L6Y9PvthlDWF0+DcInQfEiTRPCPwANxsOoUqoSIYgi8L wSzPjgTV8WQ0/sXkRYIknPcZSPtxn6HfxVqxW2Tk4SpjP/uN0iNdp6gbJ9r+16BVyiWD gky6kLRHQGht/tLkIRgHqFubSRTkL6OGwjg9EEK54nj465+R/nECrEo8KgRCItak8Bya dS0wRroo8+ECXw/1ubDWUs7YERMbI25SuXWb3XWKs9WshStv5E3sCBea4xhmznd1++La u5ww== X-Forwarded-Encrypted: i=1; AJvYcCX9Xp6ZzabDe99titwAMCQKeMaL5DdO5kxkD18rDQzDvqfFhDsBCyA5ht2qxXO20DJizs/q367zBQ==@kvack.org X-Gm-Message-State: AOJu0YzVAq5pFc2dd9sLfMlJIcKz3H9QsYG4Cn57nK2i9kVUjAuqmPNy YYB1tdMNwgZLXAYtn8D05N5NfVBN7VO0vBQ8GmDTQeflwwFysenSshGmrzNOQC8= X-Google-Smtp-Source: AGHT+IF2hWzIo4nvH7VaruPdmF/MnzuPCFARU8YeDyU0mXMLL5O5B66d3cJOBON82KFLLD/if11uUg== X-Received: by 2002:a05:600c:4594:b0:426:6d1a:d497 with SMTP id 5b1f17b1804b1-42bb01b993amr23949655e9.12.1724938583239; Thu, 29 Aug 2024 06:36:23 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bb9593c32sm4208105e9.48.2024.08.29.06.36.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 06:36:22 -0700 (PDT) Date: Thu, 29 Aug 2024 15:36:22 +0200 From: Michal Hocko To: Zhongkun He Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, lizefan.x@bytedance.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [External] Re: [RFC PATCH 0/2] Add disable_unmap_file arg to memory.reclaim Message-ID: References: <20240829101918.3454840-1-hezhongkun.hzk@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: DBF3A18001E X-Stat-Signature: dto84e6yfbnt6rbxdm4g4nwu75z98x37 X-HE-Tag: 1724938584-332464 X-HE-Meta: U2FsdGVkX18uPYwT2+JBIbNgEWEFTKcaZjuAGuTuPBpc0aJ1Ii9+h7nRGMlweXR+xsR4ujgNztI8oxozMymPLWulhHr1K0M0TY8bK/iKGFRk8f/o3X336R8qbH84ORxDgn35moFgnB2gJdWQv6f1zDF9oyUavvbdQ2kkAmkTeu1iVcHXbn8YSgXo9glQhCHJ4CbOnO8+hsx7WxfOYgSsIPu4K4RTbxGcMD5+JGtUoIApBP1LIZaOhLq1Ywo0LeO45UEf1hMGTcBNb+zoeOWPAk81Ou5H8OjxvVYxo0t8EZGq+L5rkYZaTnZ9s1PkLw+hB+clnL7RGmDMpHwjeXDnS7RCa0xRP0Yd8W5xkqOFIc1NNBdJEn+IB/z9XntojRbA4I5lQmKDaYuceU9PZxjD3pFBr7yGnHSklTIxllxJsVn6wrlsqPyyx0oqLIXoSVApBTc7P8UCzao527y12HGKe3JYw0Sq+BoKyZo3IUBVGw/sj7KsiQ3e0zA7pedAgl17xBkifP+hKuYwDmwEiAreyGn7Ms/ZoVzzkvXbmr91519pofqqQWP114/9hDIAWyNhKhfCjCDwAIwI4014mgFGT6XJ+vIHMF8TheYT1Hfp9RUfNEy1weuCco0V5xKvA+f+iryn3F7LZfPKDGlkuWxLZmXL+PbyeKqWYgdp39yry6FViEoBjgEgB1fPQbt1P3cCgCGis+OkHsZ8HAFFqQNBDnfCHjVXnjUpaXpbdEbsiDutjV/cgsahzqcHPfwTJ1n2ehwck/dvyt4lDG4dgMoMdaVyVSJqRFk+qY6cQpwytMPPt6y0aSXZ2xnEdP019sW9z1Zem/UuOhHtt+U7oBNYGGeH30l94Y3QzF7ezOAacDk2tWqBlgtyERz0ce1JBheu9vAwlkcDdqQbwT4NX94a3OETUSiuBhPODMvQpre1OQmu5OyjP4Gn0MeN/hhU7LPpAQU9Rxg/nNaPAzvZSOt fYln+z0n EIo/Tt0a0mB/UOrvo5X8CfDhsBIoMcRYzqUEWQvl6xQxsmzSzDMmpdW6xM0hBoJu6vX3oiNS7hzmXDCqJMcXOkaIBBSjkPigk8pFhVDmWPCPWBjMbCreBfXVHjVk3Tq8Z2MPA5GVX3zjfIUAZyJfg5pSpYqgbR13sE/t6DLsUhY+ECo3l5VlenyRhocZvBr6CrMrQzGInlF44rfDiVTZOjnBdDeSO0GYCbajckFKZB7NouA8h+MxH7aNkO950WqO960LMxrdiMhLcVujZB9pqZ3eCARYHJsqmyCt7QivO7qNKJHb65JC8V4Ch7iU+y9ltloBLBQJr5qV5n+q3GqVBcjfsdgoNYg+GHJAREf8xGE0ZfSfG2ZekcyUMAGTlBnLc7lpiDqBrVfCn5WewWM6l00N0+UgWL5l7V9j4HQuVoyyYbw0RvwYKZVFlQA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000028, 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 Thu 29-08-24 21:15:50, Zhongkun He wrote: > On Thu, Aug 29, 2024 at 7:51 PM Michal Hocko wrote: [...] > > Is this some artificial workload or something real world? > > > > This is an artificial workload to show the detail of this case more > easily. But we have encountered this problem on our servers. This is always good to mention in the changelog. If you can observe this in real workloads it is good to get numbers from those because artificial workloads tend to overshoot the underlying problem and we can potentially miss the practical contributors to the problem. Seeing this my main question is whether we should focus on swappiness behavior more than adding a very strange and very targetted reclaim mode. After all we have a mapped memory and executables protection in place. So in the end this is more about balance between anon vs. file LRUs. > If the performance of the disk is poor, like HDD, the situation will > become even worse. Doesn't that impact swapin/out as well? Or do you happen to have a faster storage for the swap? > The delay of the task becomes more serious because reading data will > be slower. Hot pages will thrash repeatedly between the memory and > the disk. Doesn't refault stats and IO cost aspect of the reclaim when balancing LRUs dealing with this situation already? Why it doesn't work in your case? Have you tried to investigate that? -- Michal Hocko SUSE Labs