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 5D69FCD4F4C for ; Mon, 9 Sep 2024 07:12:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E82686B00BA; Mon, 9 Sep 2024 03:12:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E31E06B00BC; Mon, 9 Sep 2024 03:12:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D224E6B00BE; Mon, 9 Sep 2024 03:12:08 -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 B5FB86B00BA for ; Mon, 9 Sep 2024 03:12:08 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6034B1A1E6C for ; Mon, 9 Sep 2024 07:12:08 +0000 (UTC) X-FDA: 82544330736.30.2E0E2F7 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf30.hostedemail.com (Postfix) with ESMTP id 552A780010 for ; Mon, 9 Sep 2024 07:12:06 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=OOMaAftH; spf=pass (imf30.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.47 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=1725865875; a=rsa-sha256; cv=none; b=RVyIU+AyQJ9NspW2btX+KpApALPtCoTrFFgnBE1yajIH0H6QkA3obfNPH/7Qzn04nsO08a yVQzCnHAhZvLbTzgG4fybRXMijxpW2D7bl/DI616Lzov5AuCuHtSZkkw/84ORMqWGPK2ko oWhVBizWyaXspifPIm6yzqe+x5nY768= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=OOMaAftH; spf=pass (imf30.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.47 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=1725865875; 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=vlTYWtVvC3Cne1dBDJYb0hBguVyLh45bhCTkFwU2JeQ=; b=H3swBzPeOjLukgUc5sciNaUG15FgQ2o2jrFpJIh8z2+qvB7yvDvkXkc1Os+0O6Igu+RFRn jjhDZaxz+7WOSbZa3Z0ncBh4z3sDORNFTnmLMFuVh75mLRZrjkZa4oiVXp2O107091RBdb DvTtoX2KoEN3t/c2+teCch8hbKKwLPw= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-42bbd16fcf2so36199535e9.2 for ; Mon, 09 Sep 2024 00:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725865925; x=1726470725; 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=vlTYWtVvC3Cne1dBDJYb0hBguVyLh45bhCTkFwU2JeQ=; b=OOMaAftHi61hi+Rodue3sgKqss10tjbkytjYjiiUn/+LhJRPOOvTpDUIzlBxRMGGKU 0Tkn34fUAEfSgbIil1vBKOZejayUi25+5wnlMm69K2zHFTF3jqlYWQtlfURLpFGbXTap 1uBl1f1oH2gnTB7ZkwwopJD2Vf2sA1Mm4Zcw6719SQ9hNOPtGh1nwhAg9TgnvgJz2QY4 AOjlruiPHEiEirvMd8tLBZISvtmPEwGoTqpKXBq/91keO38XNW444Jc03tzfuFW5IB6/ vchbJ6Jq0sskwPC8LUabsJeRsKwmqMJwgiotL2BWsfgEQgsttCgFhjppb2VmnjGNOLn5 Gwig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725865925; x=1726470725; 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=vlTYWtVvC3Cne1dBDJYb0hBguVyLh45bhCTkFwU2JeQ=; b=YXo8Z9rtU+EWdX5Dx1Y4tM/H10OtX9A+hWEQIMvFzdtDryKbHCkR6twekky646rV8N tRiu69/w6sSxQn9KW0OKaIUXLU2JiorhMjMtULMXxBbwkzD6giwDmYe1rAGGmvjkCvro aMrd5KcdaSNaCLR+dFdfyb45q8O+j3t0ahJjIiRwOZISJB2ExsvTVzI4AY7K0nugMDTB FXExkgOgjC+IMcPzdWrtiu1FnxnrIb9c0ycDwOOQWJX1yfgDI6cozTNMb4x8jA/kXk0d hZkOVh0m88uedIwQPFPTqXInF66MumSSE7Ud7Vaei7xbU5q4132xUSq0JXpi+oPGLH/5 EDWg== X-Forwarded-Encrypted: i=1; AJvYcCVMMXgBC/JbnqpNde4eikmfz3R9W5txAuu8hp6iOgeVTXUc5NSvlYBkmeUNpxeCdueF/V7IeXlyYQ==@kvack.org X-Gm-Message-State: AOJu0YyQCD+lxmrMvcMQFwqEmgZPB7BP6NimX2UJIwE6FHmDrrNdX0B6 +KVGCRYeShjwgvD2nB9haXyPDvbUlQ3/N8/gib3ChYpZeMg7HkeveUOgH4ygAnQSwCzuIuBTzc6 2 X-Google-Smtp-Source: AGHT+IFngtNyJrOoh2h5MtVKCpb2qCaCLNPXUbMYEkAbhHFc2yZgp3oF5lWSpd1MZ4PUJTDOX3sNJA== X-Received: by 2002:a05:600c:c8b:b0:42c:a8f8:1d58 with SMTP id 5b1f17b1804b1-42cae7091cfmr42247485e9.7.1725865924824; Mon, 09 Sep 2024 00:12:04 -0700 (PDT) Received: from localhost (109-81-94-251.rct.o2.cz. [109.81.94.251]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42caeb32318sm66714455e9.17.2024.09.09.00.12.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Sep 2024 00:12:04 -0700 (PDT) Date: Mon, 9 Sep 2024 09:12:03 +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: <20240906110419.2079-1-hdanton@sina.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240906110419.2079-1-hdanton@sina.com> X-Stat-Signature: 7pkbuxhqp4qweaw9f9u9smkuxqepmb8i X-Rspamd-Queue-Id: 552A780010 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1725865926-227387 X-HE-Meta: U2FsdGVkX1+Io2DQgCmSsOD7gWR6yzp/16Qj7UAnS0YVUyEbE3Tkk0iM07Qq+2SILfm/8Uo3xEzBrheeUFR0SXY37tyzzEGJ236CI6HRvD3PM9e40Pp4fws1c9IXuZa0nkxLyiPKgu+B3QUWMclw8WMLGgTyDmpW83sCwxl1ox3aSQXuCmAQbygEZWGYPLEcfoqQSF7UU8GtdGZVXOosr/mDgBJW2A7QSoLzHkIcaryBciz9lamiaINdNms4IRkeRjDwyQOYWKKiYQtcGlKWqYIv6VnHuVfzMnBEEO/hJUycirrkGCC/lZAoNGN5uga2jdIn8kuwcVcwyuM3VcwDS3ri5bSKn7EHZuWzhI7LCzpH5MmUGFjvxeb5OE99iswQyRcqKEPdz0CjCdlNr2FNVjD9WaMeLHsUbAi/pWA8FKUaT10hgQ0AKzuAqh54nduDz+DkQLHypoJl8bWfxjJVlF/UpfcmidYivvNR4m6vOTTbzp7phkdEZMjzrURHyCEhCBbHaXVZWvlhyM6XX3G3EOaILWVD1LfMwMlAsn1nhbpyCAfnAs8BjJMKa2Y4cbK0970nwwk6K6HSkxyTwd4lpKty27C+J4cu/j5Ns+4SyNoC06KCi9W+4iD292foRYUG7fkRdXUaxifH8o/zsrSVeI9VIHZTn8VbKRHrpwQdL4KsxjKvPsI72A1waiqPE4wpkxgjTK79tuqKNHsnFmurQRLqz/wTb6445f4UM0pEEUTYfImku0TaLkcQGJABE2OEbq2JDB2OkrxSYyqoA8wQwGVvdxk/mg/sJ0HIHs9ug8dcE0lmx4N8QmhVA3ZkJNXKBVjNWa2h4vyfQCfbCLIwhhYuZv7rIZtDkra5ZsRt5dLl0ZmZaCt126zqxXpCqTKA/2t366tYKutT9IzRStALy9zjdoR8RNXReM0ZE0FNBPGbhCoppoOdk93i6zd6o85yenV8y+BC+T2XbVhRnVO AIy0Hkjv bQUnL1mkUbp9aHBpdOKm4DPDFRH9vJU/oNjFAvpuF03PEnOQVetD2H7Ects4TqJRn+FiXE0KAhhYl5egFhkBlATvGCCUfEdMyRiPPnVfrYCcJKGpLE7mDmLFTUg0sxfcUEyIISjpiBRlpUp8S+N4d4Wrd2LT6YTbH2wzhwSjO+m+7/5et99QwALhkw+G2d5JTzBt/t43NZ8OsG1PXgIYkjDf5pTLVgSrcsv6JS+nb4eJhJPtnRz0ImJzoMH180liZfQOPMzzot2uc6t8hziM5EgehF+0z+PjGSY/HTe2PJ+wtALRP3M6Ehw/5sJiUqU//ZFXLyZiwUwRriJ9uqBqWINXDuhuFKA+bHTrg44ey/hIXqGk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000015, 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 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? Or do you dispute the overall idea and have a different idea how to achieve those usecases? -- Michal Hocko SUSE Labs