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 4F79EC4332F for ; Tue, 13 Dec 2022 22:26:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 743FD8E0005; Tue, 13 Dec 2022 17:26:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F47D8E0002; Tue, 13 Dec 2022 17:26:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BC258E0005; Tue, 13 Dec 2022 17:26:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4C2D38E0002 for ; Tue, 13 Dec 2022 17:26:55 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 16532AB4DD for ; Tue, 13 Dec 2022 22:26:55 +0000 (UTC) X-FDA: 80238719190.22.6826CBB Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf18.hostedemail.com (Postfix) with ESMTP id C1D571C000D for ; Tue, 13 Dec 2022 22:26:51 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mSLKmdVa; spf=pass (imf18.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670970413; 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=iMMvlFVZw8G3/OYEkh9Tl//FobmRRZHsu5mvaNkLMSo=; b=zdXdNNKGhDg7Nnupt1mkYy8lPehwK3Y2btlYLrSMMDfpnIANDQZvsDAYQVMTu1ooh4toOY SAk5/Vt9Z9AB6R4Me70T6D3RtzqrSwotbh17Frz8VceeIRX05wIFm0NJU/gsV9srivj4zT fpqYN2V/uCJtU0qbNFS/VlxdNvoqghY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mSLKmdVa; spf=pass (imf18.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.88 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670970413; a=rsa-sha256; cv=none; b=BdIv8Y6IerjWe6PMCZDEDhs7T2Kr35Y1NMSPRUU11QWRzBI/FPvCybvBYRwcghuNNN+sE5 g4UWWQmrBy/g6XWfIWG3jGJeD3yCrR7Sn7D3KYf2aUeryiAnRMx/BfdOpP5nD0fVEK9Jm/ 64OoUte7Td8e/8BBKID8rzfDXWd9sfE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670970412; x=1702506412; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=+0M8x5antrTH2ifdGS7p8lYXYju0a0wkVTDUblZnIpQ=; b=mSLKmdVaVxnfNp7YloQ6Mmn+9gP1kW2gSHCU8quozLfDZA3DsacUjk84 EV3gIYQQkPWgnHv/Z0JIOyw1sSOtQdB7en72iqkiix9NoDmv5FHL1pJn2 nLsc+MgR5211cCNWh/aElix5bBQC6GHtvtoFKXgzUS2EFOWnvBL1KErUP RpCHcoecKSf7zatw+w6vhvcBa0xHpdWVilu+C3Oz2BWzyceyUrDoCduf4 nAOEankGZ0oK83d0NprAZkDCJsrhgQ5lVqCM0ah5vcw4EI3z6R6QUfjyE 3vTnM0yhLUA7jzvHGDNeegOuXUy9O3lO1WwszfgAIPRaV5pZ8AW8u4FWs g==; X-IronPort-AV: E=McAfee;i="6500,9779,10560"; a="345320711" X-IronPort-AV: E=Sophos;i="5.96,242,1665471600"; d="scan'208";a="345320711" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Dec 2022 14:26:44 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10560"; a="791097910" X-IronPort-AV: E=Sophos;i="5.96,242,1665471600"; d="scan'208";a="791097910" Received: from snjones-mobl1.amr.corp.intel.com (HELO [10.212.218.27]) ([10.212.218.27]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Dec 2022 14:26:43 -0800 Message-ID: Date: Tue, 13 Dec 2022 14:26:42 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: memcg reclaim demotion wrt. isolation Content-Language: en-US To: Michal Hocko , "Huang, Ying" Cc: Yang Shi , Wei Xu , Johannes Weiner , Andrew Morton , linux-mm@kvack.org, LKML References: From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: C1D571C000D X-Stat-Signature: cqiuo5sqmtujon86d9sir7posyqtntt5 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1670970411-289227 X-HE-Meta: U2FsdGVkX19xo33NqkvzZTsS15GKww5cYRiScFQt9ci5RfwbvxqwTTlQKTsP32jPMYuhv5clBuXxbpRLyDoFXfsv+VIwJED+dWStVlexF7oXOZPFtwnvOnc6Ei1QAsxM0Z4h8ExcHl/LrB5l20EY05J9CGe7XJuOJj+9ISREl51wD5TQ2vME1GMTtvLsjeJibIHzpxYMlMU+mvslgJ/jFJhmo8WDOCVYveaNQzdnawe9ZYmQ/9A8HSPIHUp3x4+Bn1ddLcNZV+gO2km32hMqYYtmnLElfRrjkEEHZbyb1eHs84I9j0VWWXpOKE+rDMB3LOmCzvwTUZYLoIN7mJkLkg+RHnulwQQsw7GqAAS4xQE1bK2V0bGwTtutYlFUwjaBE7cB4qmK5f0TNgIyeFbxnhu53pbhiBsu7opCRbgMmhBSNQBrzMejLKeinXZnsm0Hy0/LuoQY6ljlHmvS1pcMKF9PAW3Yr1zfHH4oSi3HKYnS7ZoRiULFalF5PExSpTznfFUDcYJ+3iaIaSDuyw//6dqGwcZu8za7YwIIIr5NTc5GnyMJTuClTl3qowL9vIwYYRwzKbPM8RNwS2p8xm/amd0nUcpQ9GVH1I4uEVKnLbW1+Hvu0QBECxcGT4YJqWyOah7I41+4c9VNzRMQ8cuB/aKOFEu2YDWqhi9G4YdW6LwC6Pl6I+iskeu4ZFwVkrtGyxukt8zVg+s5RQURriCleaeq3XidoyqTg2b2SV0I/lM3/vEDqmC950wK4KJzusZ28cTp7OwU+75llk0wWGKzH2ZGN+KA/IeumayEOflq0/J9i7jLq3Reed1n7Ig8MtKeqRC48GDXU1nTod8DWm3T135Pt/NYpgRuFnFbhArBkzA= 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: On 12/13/22 07:41, Michal Hocko wrote: > This makes sense but I suspect that this wasn't intended also for > memcg triggered reclaim. This would mean that a memory pressure in one > hierarchy could trigger paging out pages of a different hierarchy if the > demotion target is close to full. > > I haven't really checked at the current kswapd wake up checks but I > suspect that kswapd would back off in most cases so this shouldn't > really cause any big problems. But I guess it would be better to simply > not wake kswapd up for the memcg reclaim. What do you think? You're right that this wasn't really considering memcg-based reclaim. The entire original idea was that demotion allocations should fail fast, but it would be nice if they could kick kswapd so they would *eventually* succeed and just just fail fast forever. Before we go trying to patch anything, I'd be really interested what it does in practice. How much does it actually wake up kswapd? Does kswapd cause any collateral damage? I don't have any fundamental objections to the patch, though.