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 F01E4C83031 for ; Thu, 29 Aug 2024 10:24:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 87DB26B0096; Thu, 29 Aug 2024 06:24:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 82E386B00AD; Thu, 29 Aug 2024 06:24:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6F52E6B00AE; Thu, 29 Aug 2024 06:24:00 -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 527306B0096 for ; Thu, 29 Aug 2024 06:24:00 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EB069A04B1 for ; Thu, 29 Aug 2024 10:23:59 +0000 (UTC) X-FDA: 82504897398.16.BC82624 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf18.hostedemail.com (Postfix) with ESMTP id F03EF1C000F for ; Thu, 29 Aug 2024 10:23:57 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CzqxAhOP; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.51 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=1724926949; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FpM6Nu+nGTdBDOnlln+7hjSWR827MYH0jprVOFPNg7w=; b=ngQnsn//pl2SwsvePA7YVp4+QHBrsZDHzt2OTZex1I5eDrcw3V575o793Vd/GBLglg7g5A nM9sHUqyAmMTOOrp551iHTkDaANbEcMV/Z16TrMGMDk1iTO6ef1QGJQ953aG6f5j0qS3yO AZAsfalDR9QiNg5ea7XS1ETCKLHZHAM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724926949; a=rsa-sha256; cv=none; b=clqx7uvkZsOPRT4Hk1zr2PVaDzY3xHQITl1aqLaAgoKQLmZC84fzGijuA3fO++KyZaAmZB 4vQfil5olhJejlIbLLChzqD2LfGKtxy1fyEScX3B6mV5iMa6AHzPNQkNq3tqDmz3aPEGSU XFUyRObnvusM/H0JwXSoxQYVzW7uMlQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=CzqxAhOP; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-42bb72a5e0bso3526395e9.1 for ; Thu, 29 Aug 2024 03:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724927036; x=1725531836; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FpM6Nu+nGTdBDOnlln+7hjSWR827MYH0jprVOFPNg7w=; b=CzqxAhOPqN6qI46DQkxC5CVMMfycOclKp7XoTwC5UEIaBwxn8P34tF8c/c8UvNuNa7 Bzc1ACRZUsZfj85lP6XakwuVfObzIKeS6cuNz2nd4RuwAiAgHoiGFPMbX1mV4STi0oXU N1BpZ/q/bl0C6KWNrNbfbMR/L3gb4oDDZeq2RRN9AQ9VhrlEfg1GQpJ6QnPABVzdEfE5 +/VI+Q43M4zs8TaIX0fodiNpdg0NWQVooIDcJdu8bMIKTPVnLQeAfmiOkqyyT7MD0iCT QNueWQ8wU1oe+UPq8n0BQDOhGj0LxhyKar4EpdkZ7Mes/LLKIVf1wV1ZXK+QvsmhYsri SLrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724927036; x=1725531836; h=in-reply-to: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=FpM6Nu+nGTdBDOnlln+7hjSWR827MYH0jprVOFPNg7w=; b=LzhnkWgzbeWg+lWy3cTEGtFaZvPbQPWt1a5P/hhrusNoaNlIRGuDpSXdxVekiC3ddk GsbdPC3SbX4GMUlzV7dRR9YewHjudU2vyNTYexqpVPAYP9LXYopBeChugjFpiFn4yfZC uW6SywpUVUKWJQoODZ/k6qdzByHAwcHxy1dbxsHTDTnaga+JoPq6aTaBhELwxKA6EOyo qHsl8miuEbwagVNyvopod6EyO9pMszk/dP6iupCdtLSytYyqq8KK950QGsSyZLZlpTTw UXO2rI5u9INuYa4eCCsS2sUOKPBAcII1a2KIE5yMiR6NTcNOowf95pD6G/EZcipxMhTd xq+g== X-Forwarded-Encrypted: i=1; AJvYcCXdCrt2r49eo+ZMh2BfC0DNXW7QD69cdnNHTZmry+GvcBrKNciad4k63TrTvafFvM9Z3vOLzaTi9A==@kvack.org X-Gm-Message-State: AOJu0YyTxEVPnHLipgNZdhDmVa5crGD+4BXyDvuC8pi+gBUnAwU+bdC0 eTLDoMnToHE2dsnCTTn5Y1FTzC09X+RwmJ7q4hdPoSa08VMWgGJCcr5a+tAUDt4= X-Google-Smtp-Source: AGHT+IEdDHd3BL09vforgTUgQS7bf4tn7UQrs3kUPM7WXz9LrzDjlxo2BxV8RIwgmi0hvVyJFs4B7Q== X-Received: by 2002:a05:600c:45d4:b0:428:36e:be59 with SMTP id 5b1f17b1804b1-42bb01b4453mr17782455e9.11.1724927036327; Thu, 29 Aug 2024 03:23:56 -0700 (PDT) Received: from localhost (109-81-82-19.rct.o2.cz. [109.81.82.19]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3749ef7e09esm1022710f8f.86.2024.08.29.03.23.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Aug 2024 03:23:56 -0700 (PDT) Date: Thu, 29 Aug 2024 12:23:55 +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: [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=us-ascii Content-Disposition: inline In-Reply-To: <20240829101918.3454840-1-hezhongkun.hzk@bytedance.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: F03EF1C000F X-Stat-Signature: xsoca6s6575kizc9b8kihdpj8uzi9prx X-HE-Tag: 1724927037-932470 X-HE-Meta: U2FsdGVkX18krgy4k4nYVpbQV4nbp9OYpqjEHijEgBAjz8aQLvRIy2ds7ERu7sHKTq4cXimNO72zjM514hcbZ98uHVPDt6+vKT9pWTSEShAgeoWHS5p90lOWoV7VlQebzXWgK9KVgzRjRHWLAT9nmKXGMU3DXMsKKgPbqFRG8JuZfb8JEipQ80IDpCNtB67ixTIz+G4MOCu//1le8XR5pUF1Y+ViTiYMnbYG/BfXJoMFZOeI/XPrq77MqCeKi/wD4hOCRRpFOfsm4NalM6CHcYTBdRKtoUfLPDX/UZ7/zUdX6qDKG1kKByx6waRaQTxmfQ35JHy0RKuipYCm74v/yDetvvHjcDMRw1dOGLCVjYznNGVENU5WHuhaWGyU3Tlfx+im7M86KKJdSWUnzKkVDvLksoayMPXCWqbRDYxSU5SOK4OGvOTv6l97d5WLBFXTYJR9D5OczH7XIw8bhWmgInYaVWyRExEEyc8xGDbwGpGyLbbBoikUqzmQOmU5J/WZyeEsf9ISO+vI/ScN0UVEOZgLuueE5fPZhre7JkKrVyYxHCB30k5dyZ2rfYapMOfvVOyYr7V50hn3ofGwi63YpYbr2B/bxSnhEtih+ZhD3Jk3UUPsK34hsrCGTDJR3mZ2Um8Yx5XUt25rCU26Z1IfTNFA9r9Kkjc9AVa1mbSOfRu0RZBVkPDZ92I4+hJuSNqyRgRLNNBzB8H4Nl4eyvViL94Q1f+4G7cil3/UNepS9PFV/k2+lncVrdGLPCXbcl2Vg8gH1MRenc9Pxdnbf3xc+jfl6ca8X4tPoQ6lVKhqRG3LEWNWbZMXoG4DOOuod7meTo8WTfiYRr+UcI5yz1c7SnwvqXsiI0zCz5b5WVJhaGFOJfi5AyNapamImfrquVz0OZJy6Cn9UzhbpZwlUKnK23Pa4myItbkSUgtyxfumquNAP57FexMGc0Psnfza7iT2Y9rzP6beV2LUOow3NQ3 ZeVp9KEu iamE6n3Ul9RnoNG3Y0br5kgM2dCLX/B1W8Px61XjVBtLpZRol1qX9TVVxYegWik4HEJCzLwCsh+eYf1bfuxs/Mgd9wyUQPk9bHaJycwYhbauO3GvkcxW8UH9RfKwulbys3xvr8fJlzeb9JAO7gkAFaA+4aEVaIQiQIcN3J1CN2+SFzrzgrYnFod2Vq1QoYFlAVqYcwjpqPneC0EgFoq3I2cMbk+gBGjx7ybr3OBsFooifiww1dDaP8pb4KhNebJt+1ktMkx5tC7e4kJxHcROjsq+Vk2FzNj9fJExld7vSq5zILtb9vI8g+gVzFprBYUZARN1B0+uZ9PkWRnICEf/W/9UVWqRI/IuyR5UI 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 18:19:16, Zhongkun He wrote: > This patch proposes augmenting the memory.reclaim interface with a > disable_unmap_file argument that will skip the mapped pages in > that reclaim attempt. > > For example: > > echo "2M disable_unmap_file" > /sys/fs/cgroup/test/memory.reclaim > > will perform reclaim on the test cgroup with no mapped file page. > > The memory.reclaim is a useful interface. We can carry out proactive > memory reclaim in the user space, which can increase the utilization > rate of memory. > > In the actual usage scenarios, we found that when there are sufficient > anonymous pages, mapped file pages with a relatively small proportion > would still be reclaimed. This is likely to cause an increase in > refaults and an increase in task delay, because mapped file pages > usually include important executable codes, data, and shared libraries, > etc. According to the verified situation, if we can skip this part of > the memory, the task delay will be reduced. Do you have examples of workloads where this is demonstrably helps and cannot be tuned via swappiness? -- Michal Hocko SUSE Labs