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 83C6CECE57A for ; Mon, 9 Sep 2024 14:50:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1B9136B0180; Mon, 9 Sep 2024 10:50:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 169686B0182; Mon, 9 Sep 2024 10:50:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 030AD6B0183; Mon, 9 Sep 2024 10:50:07 -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 D7EA56B0180 for ; Mon, 9 Sep 2024 10:50:07 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6DC9D80559 for ; Mon, 9 Sep 2024 14:50:07 +0000 (UTC) X-FDA: 82545484854.30.3D43BFE Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf01.hostedemail.com (Postfix) with ESMTP id 86D5A4001C for ; Mon, 9 Sep 2024 14:50:04 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=K7WN07Pq; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725893377; a=rsa-sha256; cv=none; b=hMHdzZAK3corZq9r8UoO/9MyordQCqBUNa6FiLXG1IbnnWVd/YRqpixtRUkBVRRnmsQBcy a+bY2uSGVwShhaibEGn3BYCAmcemwddWN+C5wexjwOAS16oobSuGbyhmrTq0mi+S2u3XEf PuOTDcy7WZRCJertqTu5/j1O8W7MJGc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=K7WN07Pq; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.47 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=1725893377; 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=+9v2Ew7hhlLr4kMPvE7YVmpXKAISPQ2qnVJhqFoRzg8=; b=HAS9nUADUt3/7kCcJzhsO7Ppkhc3jk0IcqbjA8EETpHBG69Ml7ScDm6ow4CbVVafsjGgDi W2LTxD7JTu07tWg0rCPCK/Y5ujRhGe+Qk1x3crMKKM8vQBrWNQd+1nNZa/+vzwCqIhc8fx ABGkJdF4nnfx+0/lc/41CXiNDFbtxLk= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-5c251ba0d1cso4679460a12.3 for ; Mon, 09 Sep 2024 07:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725893403; x=1726498203; 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=+9v2Ew7hhlLr4kMPvE7YVmpXKAISPQ2qnVJhqFoRzg8=; b=K7WN07PqilSXaKmC3JPfGYV1QpcQez5Vpt0FfxC7cz6N3Hln2cghnOR5ztB4fAl5bX bPWoSYlF4PB3ne1DiRtdto73/k05aRXHjtIWdX+psW4SDmiuxZJk3ZdQVZma3BFXWlb7 CApAoCHGJFUyoz2KnI4SvlUpkm8b3eXWGfxaiVVVmcmOsddzZvM6JwyrkEWDvfzKY0kB 1IQaVVUTdCVHdKsVvj9VQrcxRhQMRqY1TbOfjvpHZuTfYdwdYdA+39zfEpr56a9CkmD/ 7uKG+6DZkFBXacJ1cyV+ahn4kdm1G+jvrd0H1QwzDjf3/fd2dle66OZO6W98AwIiFBeH YSXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725893403; x=1726498203; 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=+9v2Ew7hhlLr4kMPvE7YVmpXKAISPQ2qnVJhqFoRzg8=; b=V+rSWxB/z4kv/mKWyaZz5WTNRTbLVa0mMUuy0wSAH+OhF2D23XQri7+xJ+qn/Azfv1 6tHR++LteYnvYI2Jyj1jMXjpdtcA4B5RLh0oZ7HDujlEZbvSIjDDslOfAF1cYdVBwOhf aVu1Lx0JuCvrf5HfJUzh0v9dEtOdJpLuCZ4KzHKZifl/5Z9fg0/VvMjKcIUO40MOLYAq xDFZ5vUb3OlAW0eqid0pb5AbfNU5y/RLvAuCvY+VCV4La8sdhrlSKX6ZsTJxH+W2wHJN GhkV1CzkiFctzMz72QP8LO7fCdSYTTQV68YqS/CNz5Oa4Me+QLHJfOocB+EeZew1l6z4 hKFg== X-Forwarded-Encrypted: i=1; AJvYcCUZZtWqEzA7UEF4rGY4NxOPb5btqRwG4OWOJaV6WG69e6/a/hlhvnfaLuqsP5DTnPc2UpXVJW5nqg==@kvack.org X-Gm-Message-State: AOJu0YzvyELZ3St0xvK9hOK7M1ePQebQoy+1Sdlt7SpTDpE0wbulODPk ORGy5uArvrI6O0dWBDS3bD+1KDYUXKRdOm3gVC5k56aEnfROHW6aSF9AodcB8l0= X-Google-Smtp-Source: AGHT+IHf434hHzqA3na7vHiDZ07v1njm5O6rCFLa56eADhixaf8Z8IRp8g+sM15hDoTHcp+eFRE1lw== X-Received: by 2002:a05:6402:448a:b0:5c2:632e:fad7 with SMTP id 4fb4d7f45d1cf-5c3dc7955famr8352205a12.15.1725893402803; Mon, 09 Sep 2024 07:50:02 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c3ebd8ceccsm3086633a12.91.2024.09.09.07.50.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Sep 2024 07:50:02 -0700 (PDT) Date: Mon, 9 Sep 2024 16:50:02 +0200 From: Michal Hocko To: Hillf Danton Cc: Davidlohr Bueso , yosryahmed@google.com, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -next] mm: introduce per-node proactive reclaim interface Message-ID: References: <20240909105157.2663-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240909105157.2663-1-hdanton@sina.com> X-Rspam-User: X-Rspamd-Queue-Id: 86D5A4001C X-Rspamd-Server: rspam01 X-Stat-Signature: 5obezo3qis6i1o4wiidgtgu1owhoh3mp X-HE-Tag: 1725893404-624013 X-HE-Meta: U2FsdGVkX18ZXIf/0n9UkRpTLK5J1DY2z6ufbvDYDvKnTNnb6cFvUTvJ3UX8BCHPcM//tHoABz/aBfdNhMpVaCOvr8b1Sa9iUI3g+AMdebpIxQkadiVYLGz5sQ0YpGb4ESxjA0xL3wV8dbgeZ2KlldUFO5ZEnKyBciqFQ+yUbAfTEUmzXY19fnhxN+3irnFMBdJbxoNWbsIK9BSQ5xiGfZIiu60xmRp3t6fT6BGH4iVxpgxbMVYZxlNdS4KUC6GkgO3fTIHJ3bHJR8uToOS0zYEVPQ6CCwn9LbXklo98iPCzU3tYc/EKjbGDEW8i/7bdCzYnzpLKvWrBJu6j2oNC1sJ7fEV+0XusSjThNkoYSweLRRupaN9iYG9tLQZ2PQe+IgyEJ1vztLHpTQsEBrVzSMDehS8h1BAMR6Y/SQO9hzaih9jh1V8fYgKwqRo9Fqk8TETMqTbyA4KNaK6VThnOYgeZOBWYMP6QHKpZ37n6eGdnCNa0oLE8jDIF+4VfhOIHhWiJT69ODNDbnyZOK0hwZ9AWY74XSqJl5GcMXx0gCQCDeSrKk0vSz886VIgLWqBV2H54iOv56ZsSKOpxPl248NBdY+nBpR0vBsZ7L+OwjybG8Y1UsDwqojAbTo/HCFY+9R8XBa37xs13hwmg1TLqAwbXFQizu5KWB1cipr1vbgetuXOzn/80quDT2AiiobVYWqojZluTZ7izT/f58qBcAleKLANa+8zJ590CG2NtyT9h3L0JhIwSx1ofhsGTg2t/AjJcPgFt0Ua25qMhStFdA329h2MR6Mgz3CDeikOZKyZMAlwZe5kkn+CpypN1kTjNDgjhcPBGAQ9Cv7Cc+CmYGk5Kb0cG4mSLizHFS8QVYDkS/Gub629fGMZy0uTsNRQn35uS0hvuJLCfB2wJTql9/B9kDtiklKZNlaja+QC1/gdRNhbgCF6MoAwmtwO3kzU+Xs47RUmCspY3/2ZCeCe zYEADMcK TbOChGQNwabd9POg/0YzxGlishrK4nXY3XEG32pNZtNPSjv9ukoM5mOHBb0/pK7Ca9mUnnFBp3pX/XOyy3CeycsqtDywLcelOVWchigeCZ+TEhANiCd99ltSGPQdCNRt41ubmvo0INmxgUqtPWO06YPGFwc4t9wzESfWyNIyXBdMjhxQSO+cC8riVUu3fvUYc80O4iRSfXSJ8emKAwDkrzGoCvLR0S6j1WptO/BrRcRTUb2hYJBaXxQd7pSb7b313TTsuA4j4SmbEGmblACdZMwQewYreNDZbTaMX3me5PkCiPJhwlUu7I96VgDRgQ2pu21MbXV4ss2ebZod2grJhcTfjttl3iuj2y/vlP20AC+fukuvsptGcsXGvjNV/i7XzbBGGk9r2YYwRZP9GXJy5OT2TIMEwtUA75u1muaLYNcqfI28= 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 Mon 09-09-24 18:51:57, Hillf Danton wrote: > On Date: Mon, 9 Sep 2024 09:12:03 +0200 Michal Hocko > > On Fri 06-09-24 19:04:19, Hillf Danton wrote: > > > On Thu, 5 Sep 2024 16:29:41 -0700 Davidlohr Bueso > > > > On Fri, 06 Sep 2024, Hillf Danton wrote:\n > > > > >The proactive reclaim on the cmdline looks like waste of cpu cycles before > > > > >the cases where kswapd fails to work are spotted. It is not correct to add > > > > >it because you can type the code. > > > > > > > > Are you against proactive reclaim altogether (ie: memcg) or this patch in > > > > particular, which extends its availability? > > > > > > > The against makes no sense to me because I know your patch is never able to > > > escape standing ovation. > > > > I fail to understand your reasoning. Do you have any actual technical > > arguments why this is a bad idea? > > > > > > The benefits of proactive reclaim are well documented, and the community has > > > > been overall favorable towards it. This operation is not meant to be generally > > > > used, but there are real latency benefits to be had which are completely > > > > unrelated to watermarks. Similarly, we have 'compact' as an alternative to > > > > kcompactd (which was once upon a time part of kswapd). > > > > > > > Because kswapd is responsible for watermark instead of high order pages, > > > compact does not justify proactive reclaim from the begining. > > > > What do you mean? How does keeping a global watermark helps to trigger > > per NUMA node specific aging - e.g. demotion? > > > In addition to the cost of pro/demorion, the percpu pages prevent random aging > from making any sense without memory pressue, because I think it is aging that > rolls out red carpet for multi-gen lru. I am sorry but I do not get what you are trying to say. Can you be _much_more_ specific? -- Michal Hocko SUSE Labs