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 F0C78C83F2E for ; Thu, 29 Aug 2024 15:00:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E1966B007B; Thu, 29 Aug 2024 11:00:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 691E96B009B; Thu, 29 Aug 2024 11:00:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5594E6B009C; Thu, 29 Aug 2024 11:00:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 359156B007B for ; Thu, 29 Aug 2024 11:00:28 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 88CB7A0FA8 for ; Thu, 29 Aug 2024 15:00:27 +0000 (UTC) X-FDA: 82505594094.04.A71D9A6 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf25.hostedemail.com (Postfix) with ESMTP id 628DCA001B for ; Thu, 29 Aug 2024 15:00:23 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="Bsh/TA1V"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724943602; a=rsa-sha256; cv=none; b=SESRpPJtHDueDVBSYvFi3mvQmBOvHBw4aW1n7QxLHKhm5OorHExjQGgmEpyzg0DDRpKSXo YsEipd5NHkSycDU293M2gRo3La11KE4FhdFEa2LwULacOH4Qri7EHAF+7JcJNRyMTAZ23y sntMVVsySRi2qjDQMkXrMYpQK8Vb/3o= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b="Bsh/TA1V"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 209.85.221.44 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724943602; 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=nabzqbq3d4n7upoEt7nD8rDZUukL6YPjVtAA5PPRGA4=; b=fUv7OV4v4gd3uLeruog1A+G1SlVS7T0LpXPjMf/bryGv3AQTLJKEhsrt756ESeqU6tooPj E6zkg0msK2GgY3T4hejzLc0UsaDmKC+Rk1HTzW2AeVr6eV+zbWCGkX14gd7zvpBSiYcazx H3iXonnth9jmlwPGBgAJMX9sss37JLo= Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-3730749ee7aso526758f8f.2 for ; Thu, 29 Aug 2024 08:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724943621; x=1725548421; 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=nabzqbq3d4n7upoEt7nD8rDZUukL6YPjVtAA5PPRGA4=; b=Bsh/TA1V+UtF1EzRYZ8boJE8dwJCzUSY5EqNaQ0/rrExAnVQdSJxd2anOd2/cT4wPh c4TFiHixcDQr617s7dJuY7qdYxFDXfqcFmQqX9chsXTuUOkQEUlvbhASU0UNRxM382CM XhTdvhJuvpdP57fajxTmaR6aFxutJ9hFW8paAf4WTAB+XNqC4EP7H7QphDM5X7CmUVNL AOeDq30LR0hgKwqNpb0PdNjMscBhII8P2PbaxNReSNPE0TFQj6asIZE7GnzsDT/AYOQo nX2wwWXYZtgN2Wb4u3piq+wO30ellhbfQvO/T5ZwrFAsi1mLS2jFDy/TKTfQ0Bf7Q/oP AmTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724943621; x=1725548421; 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=nabzqbq3d4n7upoEt7nD8rDZUukL6YPjVtAA5PPRGA4=; b=OOwwx2Ss3qkPfM8ZaKYOEUS9exN/ToGbL+LCjQc5GGWHDklJHB7pJWuNRrAvlPBrbf JwJJjTwbBGJiQQ30VMMvKsSawyee2T3n6t1mEHf4jpz07oWcELalIdxjLD0C42hG2IlW PauFDksYiHYplBsfywwY+qZwDofkj2zsBoxBHesoOEta0LN3dCBNjacpy2N/ZewtAGC8 1cqu4RiaxpFFQWH9xejoeoD75PxVx7BxE+TsFePwC8xDEIpK1SrKxPT9BiyGmBXMzWWM x4gX3RckBcYOTmGbb40drDmQ1NOKEx7WWVPWeNLJ8j+LpEdFazX8Hx7MSt9qWbI6R+Oe QPuw== X-Forwarded-Encrypted: i=1; AJvYcCXY/O6GknIOQt0DBKV5e03sWUHsUdeSbGzDFrGjGP+o3Isea1T7FWmAbyCmQ0UxauT30H/d2divqA==@kvack.org X-Gm-Message-State: AOJu0YwrqQp3aPeUvMPnx1oxFgDcNwPm2q9g3SQMzd/j1velic6FZPSP guy+TEQXxr5zgK1BxfiiN+U0+73u9mAfibZwlMeGqH9UNADCUuYCGap7N6sd1rw= X-Google-Smtp-Source: AGHT+IFGM3zEq1G1Y27SykyTrp93FIcWQs50mww6UNMM9UAx7l9nMYelCvutFX66Xd9aJmaFkviA7w== X-Received: by 2002:a05:600c:3b10:b0:427:d8f2:5dee with SMTP id 5b1f17b1804b1-42bb01bb04dmr27517565e9.15.1724943621333; Thu, 29 Aug 2024 08:00:21 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3749ee4ab0bsm1629466f8f.16.2024.08.29.08.00.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 08:00:20 -0700 (PDT) Date: Thu, 29 Aug 2024 17:00:19 +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-Rspam-User: X-Rspamd-Queue-Id: 628DCA001B X-Rspamd-Server: rspam01 X-Stat-Signature: t6mrf1bqdi659sw9ehgejiqppisugti1 X-HE-Tag: 1724943623-439939 X-HE-Meta: U2FsdGVkX18VLy2wUJBDBdjZJa97nJuFbLv/A+JtjJx92jd6armBxkZUkGMQaXQmp3TJgwPX7P4gvjyl5Ia968bicMFQYmDyEYwqMcLijYaf9TXKjV2h+ggeePlqZsRzwYw98OOv208OTyK819Oa8eY0S4ebEDBsRHJlAutUjwCTwOAldQctCs+fvyx06gTfRqAO0ELg+CwSkdKeKDURuQ8I7k/JNzjZmU3AXiDkFnFrlIMJtm63Lir8YR6+Tv/c8xw+az4hsutX+ZwNCvI+oJBa8au1kn5hfTdUYuhZBxcWPJmRayV+qTBZNqfTAoIZ4P0WOEvfEpN6FvpPEupGo877dcxi3NlE5woEIJGsZa0A7KeC/irR1BprKRh7Vrz7ocgaCqJCcHT//tnOLeW2P7lVU42pZ5vq/RbyYgqdto7t7i6uGdc8AC+bvV7cvvItpcggZq5HqVcErI/Prc/EsIdklQcUE0aId3XXY5n7k2q2sYBdFKMQsC3HuVNvY8fLrjoCFabffeXle2rzgRsr4MGKBo/x28cE7ip3Uhk4WZKOIoq5wb2H4hKEQN3MG2RPxvv1hcmZlJ//SFb1WyXXbltq10JX3yHvaNsje90ilCD1u3C3QIZGSPWseFMRHXNB62w7uKTVxgJk6Mkdcfc4jYaLeeVeGI1+tRtSGo4nRLFtmdzSFMX/tJPyAsSZszynq4w7umHE0Tef0bPrD47edniJAX/pijdF6NIeqi2YS3Qd6d5oMsVaZnAlQtRXWJbrQex3SRbnhwE6B9HB9gJk07GvUcJ42UahleMoBdvnhtrnYHDWf95x9wLHEYwl5gO5IQdpuMWtBAy8+HF04d28tgGTpjkrTHOG0U01VojH9RBQg7OyISYu2Uz4yhAUryFTbBKxz5xdLGn2HSpUe387Yyz1d6UmHn+C7ecIvO32J1Y6xJTBRfjsoi55oqoyZmFkfGgBOSGpcbRIgHrO/6z 2BmqwHFM t/k089uwu858b0Iy6maLPj3rlCmWLwOv4PD1jvWJ7ZOiiSymzTGsB1Lero2NBzewvEZAulf5DLrHiP9s4C0Z/+VDQPoijS8zZGk4qE6jhZfBbpf4Ye+vWsGCLw51r2WULdEOTQZMqZzxvIVQCTRbDfTffIiwl5Ejnq0NnRhqVar9xStprqn1leD/Pg3918hO+LYt+P/EXK29kVXFvpO3EcMEgRzkALRZOnmuBBuJrUcPzpr5l4SNej6ba6amDmQZ0reEbmKTLDd8HtBkXozYtK7Cj8MF0Zcc/8qGzarAbese50jpJt9Yr/tRf6x3KS0eidH6guLEqNhR+iMCf0v3jrfZ13PiJqj8OChIN3XZHXiTUAD6wLBj552P3D63xPYilz7xg4aiNC6KA9U1/1kaqlatfmt6niksVYrmFwYlWY+WGoXrati0KZO8kDhwg0Q5ES9bGrNbRINQPvn8bO7qdHYT9LHZO9cJCPkL8dpP4y4+pVysfXeAsRhPahLEq03kaadkv9h2sOhS6BMn4QjVPvLSuMjEN4bZUlTu2vdhejo5ysg7tlEGbUoGq+w== 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 Thu 29-08-24 22:30:09, Zhongkun He wrote: > On Thu, Aug 29, 2024 at 9:36 PM Michal Hocko wrote: [...] > > 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. > > > > I have a question about the swappiness, if set the swappiness=0, we can only > reclaim the file pages. but we do not have an option to disable the reclaim from > file pages because there are faster storages for the swap without IO, like zram > and zswap. I wonder if we can give it a try in this direction. I do not think we should give any guarantee that 200 will only reclaim anon pages. But having that heavily anon oriented makes sense and I thought this was an existing semantic. [...] > > > 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? > > OK, I'll try to reproduce the problem again. but IIUC, we could not reclaim > pages from one side. Please see this 'commit d483a5dd009 ("mm: > vmscan: limit the range of LRU type balancing")' [1] > > Unless this condition is met: > sc->file_is_tiny = > file + free <= total_high_wmark && > !(sc->may_deactivate & DEACTIVATE_ANON) && > anon >> sc->priority; There have been some changes in this area where swappiness was treated differently so it would make sense to investigate with the current mm tree. > [1]: https://lore.kernel.org/all/20200520232525.798933-15-hannes@cmpxchg.org/T/#u > > > -- > > Michal Hocko > > SUSE Labs -- Michal Hocko SUSE Labs