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 0C4C0C54E60 for ; Tue, 19 Mar 2024 13:40:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7002A6B0087; Tue, 19 Mar 2024 09:40:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B0296B0088; Tue, 19 Mar 2024 09:40:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 551AC6B0089; Tue, 19 Mar 2024 09:40:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 42A676B0087 for ; Tue, 19 Mar 2024 09:40:47 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0A6CCA17D3 for ; Tue, 19 Mar 2024 13:40:47 +0000 (UTC) X-FDA: 81913898934.20.1391E7C Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf04.hostedemail.com (Postfix) with ESMTP id C75B44000D for ; Tue, 19 Mar 2024 13:40:44 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=HNys9iGe; dkim=pass header.d=suse.com header.s=susede1 header.b=HNys9iGe; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 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=1710855645; 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=gPnsq29Wc/buvWIEmuCObK4jFQyJYrkPVaoqmvReZ3g=; b=e3LVPL3La6//XGOma7IKq/Ar8WvtEo+YRdE7WDJC7xWw70hGJzUkLHedLmVFNDSR5okS4T y85MY8DhWUE4dDG/+04vHV/U3JadIl05h4853tFjHWWls3uAnp4ZoveygvmfIpkuyTREhf fLrRCOQZhEoB49EiXY/MoScs2bsX0sk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=HNys9iGe; dkim=pass header.d=suse.com header.s=susede1 header.b=HNys9iGe; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710855645; a=rsa-sha256; cv=none; b=W67kqyULKqUI+CTk3L+BP1Ynn6quasx3GUgXSisMwXE8tO03ZNhDtITyjmcXTA5NMK42GB lbLDKsHbHdAchnhGaLaqOPMcLQDYVpm/WAZVO+3iRczfoQwtvYO8MEtx5u+ACIoZMlp9Vx bgeDI8bd+qKSXoWm0Qkaakkd+h8iUYA= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1F5495D714; Tue, 19 Mar 2024 13:40:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1710855643; h=from:from:reply-to: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; bh=gPnsq29Wc/buvWIEmuCObK4jFQyJYrkPVaoqmvReZ3g=; b=HNys9iGe2SR/wFIjkvSlF8NHw/ARy1KUUGVVXmmib3rYzIqtQMQgy7Tc/LDPFq57vSrfqP 4AePwczBpK/GQevULP+7L6FytLrElZJcjZUf6qUhw9mMAKz3hd4FPqV6z+1qIRh4/AONiG IeKogcEvtKvKAtvAoXV+EkA8cw09sEc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1710855643; h=from:from:reply-to: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; bh=gPnsq29Wc/buvWIEmuCObK4jFQyJYrkPVaoqmvReZ3g=; b=HNys9iGe2SR/wFIjkvSlF8NHw/ARy1KUUGVVXmmib3rYzIqtQMQgy7Tc/LDPFq57vSrfqP 4AePwczBpK/GQevULP+7L6FytLrElZJcjZUf6qUhw9mMAKz3hd4FPqV6z+1qIRh4/AONiG IeKogcEvtKvKAtvAoXV+EkA8cw09sEc= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C4F0C136A5; Tue, 19 Mar 2024 13:40:42 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id AIUdLdqV+WWraQAAD6G6ig (envelope-from ); Tue, 19 Mar 2024 13:40:42 +0000 Date: Tue, 19 Mar 2024 14:40:34 +0100 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: liuhailong@oppo.com, akpm@linux-foundation.org, nathan@kernel.org, ndesaulniers@google.com, trix@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, surenb@google.com, zhaoyang.huang@unisoc.com, quic_charante@quicinc.com, yuzhao@google.com Subject: Re: [PATCH v2] Revert "mm: skip CMA pages when they are not available" Message-ID: References: <20240314141516.31747-1-liuhailong@oppo.com> <20240315081803.2223-1-liuhailong@oppo.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-Stat-Signature: 51bobm1w55bnmsg7oge9ep697h67ntn6 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C75B44000D X-HE-Tag: 1710855644-147168 X-HE-Meta: U2FsdGVkX1+QfVDjKo5uvMRcdYVOp0y64oGQiwlASAOMFc3PqkXHj5Ef73urn1tufL6C/nqVJBnbzqPEcF4JsSRr3bJDYvmuTQknbHjVQtWjk7D/R/Xs+pFtb5duWBpNqG0Gg5UVyrVqEDoQdjWn5pQs4l4vo/g/smvgkTJZ/O9RfjM3oyZJlVgB6FsC1zJZkQxygk/N0Elk5tMk1ckVZUsJWo2NJTNhchH2NCIMOyDv2Djh3b5GqkGuijwFwi43BFgZvA81ikW+ppNKGNLPCk4FueUKrp+OVwpVQGSCEC/DexUPYU+Y+Z8/W04OJy6V/2DVbitTQphFUqz0sJU2iBESweY1hgLTEcuxOdJrHLCLAiFx63Y5a9/fLHJji2jwsKzCGYeMMf2VAQN82R9DEqThmSzz5qdELmcR6GD1RyoMzWxaSeJpJoD+QTP9WPxQHJre7pbgaUszAc2jV5mDfFMk5vmMo+vpuQOiFZKyLIKGKRwC6jbjgsQwabuTasQz0q2tujIOKop7I3BnALqyIHHVNI+l+yG974TG5Fk0+GVb8Vzf593bspSk0HxLRhmWOioipRgisgOWBb6dne/uC2M/0l7pv1G7EkFb8blNFAK1hktrANZmIhfzKqRiXrBSHFcff8KiSZlMZUIM1/RMDLajdkLueZL7uczFCMl2s5UDWn8Sqsa/GB+nauRIzwEkdRTd6fkq0b9f2MSwp6BSFyZG4/LnEvcPKBwjBmRMEb08YmhEU11mLdloGziwBBY7L2lkFtI7jRF+VzJRkaClGzMZyoK8+y57uVHGjJLf2HW8QoXLSx7K1PSgWwBjXh105GyndQx23c+xfrivmX1vqp12VfEVJFVRoUc0sg3e6q0fVe3SmxYdN8IUA8TyiXdYE4T+5kbxq04IUzrziKFX3YTOtk/OfmX5UPWqQoWIaapmYrIE8QwYsYmPWA8FCYhwcORC6wvv55bjR2zdxqo KGNAikzq FW3ddys3UliQexwwm+JGJucwoFKGskt4KuXh0UR0aDua4A41/FXS/H9lredxMGxdvaTdUT8HZAmnDzSf8RI3AkhtYQKDnvQJmNdzUBkvqwiqGBXEtlh2tj1u5mEKuPCvqiDgp5h2d1AoQuCoLrChZjaK0tnskItRv1qVtiQTH27Y4q7QVX9Z97BB/1jtgpR44hZAywcuGxQD0OSBk+9Y5dMN0rQmYhQvKV4ioGJC+I6o4s3XaKKPkzO6bOPx+p9Q04z4gXWqKGN+LR2nXGY68+WnCxDsQiy4dmwWLjrYZU7G4ianVdx/lmAz4/eCqv/GaoDTAslIOnYr69/f9pryYTWXtUynkLDAS2vCLXbQcMzz/S1A= 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 Tue 19-03-24 19:09:18, Barry Song wrote: > On Tue, Mar 19, 2024 at 4:56 PM Michal Hocko wrote: > > > > On Fri 15-03-24 16:18:03, liuhailong@oppo.com wrote: > > > From: "Hailong.Liu" > > > > > > This reverts > > > commit b7108d66318a ("Multi-gen LRU: skip CMA pages when they are not eligible") > > > commit 5da226dbfce3 ("mm: skip CMA pages when they are not available") > > > > > > skip_cma may cause system not responding. if cma pages is large in lru_list > > > and system is in lowmemory, many tasks would direct reclaim and waste > > > cpu time to isolate_lru_pages and return. > > > > > > Test this patch on android-5.15 8G device > > > reproducer: > > > - cma_declare_contiguous 3G pages > > > - set /proc/sys/vm/swappiness 0 to enable direct_reclaim reclaim file > > > only. > > > - run a memleak process in userspace > > > > Does this represent a sane configuration? CMA memory is unusable for > > kernel allocations and memleak process is also hard to reclaim due to > > swap suppression. Isn't such a system doomed to struggle to reclaim any > > memory? Btw. how does the same setup behave with the regular LRU > > implementation? My guess would be that it would struggle as well. > > I assume the regular LRU implementation you are talking about is the LRU > without skip_cma()? No, I mean standard LRU reclaim implementation rather than MGLRU. -- Michal Hocko SUSE Labs