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 316C3C54E58 for ; Fri, 22 Mar 2024 01:28:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 970A16B0083; Thu, 21 Mar 2024 21:28:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 920D36B0087; Thu, 21 Mar 2024 21:28:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E8A66B0088; Thu, 21 Mar 2024 21:28:58 -0400 (EDT) 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 6EE256B0083 for ; Thu, 21 Mar 2024 21:28:58 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 44D9FC029F for ; Fri, 22 Mar 2024 01:28:58 +0000 (UTC) X-FDA: 81922941156.13.2FB9E17 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf15.hostedemail.com (Postfix) with ESMTP id A9616A000A for ; Fri, 22 Mar 2024 01:28:56 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=M5F8L1kb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711070936; 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=elX0v/wzn8FOI5S/DSgb8r/0YEFXzUdTLBxZj76WCmE=; b=vMONbOYwqD+R8XzS1UtS0lvZUQMvrdxF3etu0OPAMrLzavvoQ8XJEomEcmtGdb9feaTQLV IzI2FmyKSEyK+SS9f//vPKk+nNUlVuJe4J+1VyPL3VRW/dJrfzWtr5xZN4Kk+L3D2t5XX5 0H5qkKC4zCjP0qxuLTLgYIhQF3QO618= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=M5F8L1kb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711070936; a=rsa-sha256; cv=none; b=0ZMGJFgoDOI52TjlamoY4oYomxXyTLFK0997XE4ZGNxjTHT0wAaPeD9LOrMWWjGhmQE06m vvX6D+MdSE3ITHCJ7xzwaM+pueP40KM11l8EFXvn/ftt3HHFZLIFhpd/Rfyf/OPMpGv4bL wgKrjhnhDJU3c9qauaOvS7p7rsR0J84= Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4d4585339ccso1473714e0c.1 for ; Thu, 21 Mar 2024 18:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711070936; x=1711675736; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=elX0v/wzn8FOI5S/DSgb8r/0YEFXzUdTLBxZj76WCmE=; b=M5F8L1kb+brbLmPqIj49UYIGHIHMGwM/+ggUzb9P1EVpRWQKctUxEAjIUtrHdZWmEO kNr+iepiwYzupWGiPmOYZW0oR7TTphbmZI19cTKp43Zj1kSArq+RkxBazAMzmws0+kbz 8+6HaLWLDzj9lQ2vt+TKpuaHtNW1nbSE4tN/a5x4xbFam/1gJZTkGYUrQRf/+PA+FsCd HMGLQSzcy7UzoFg2sucwaxDQc3OIJ5VQNn3J8k4iBfqr507LrEaNJw6Oh5LDzj5qNkbp 0sUy8pCDkK80pboq+siZF7ppC2+ovfLC//fJErtrnaLJdElVgxfll4K0zoMH/3QikHlG ou6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711070936; x=1711675736; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=elX0v/wzn8FOI5S/DSgb8r/0YEFXzUdTLBxZj76WCmE=; b=FEpbEDAZ+w/MVhKNjEV+oV25O0l1pcPdqt2P0PPXWBBKfaZIN2E1OHF2HAU9XhucMJ np1ANaQ5qHCbuEoQrU4zjnOGior9h6r6n3w9sunuXRBZ7oS6q0AlTG3qD9jMeRaeu9cQ e1p4vCuTUik4oehCFoyA6g8rByhxqUyOSNjQL47s/nhki+jUWl6Mzk8mg3QUodOLF8sq dbU/YOmq2eSmt8P6QsEryvLczzOmdLZc+dUHLkB9GVNBxQyu9nDEiS4rAjbvsFP4bNVp V1yM1yWU6qqJzmqIm4tXcKkxgkQ0Snm/aNNhysDbL7KGXpVU4hDehBk0IilcIJpB+vKu J0RQ== X-Forwarded-Encrypted: i=1; AJvYcCWgpBLJtkiKp/B8Woc0/4W6/yjLvYalaDUM7It+FTSnRxZ8WHUxlv6VjckSn35QFtEw13gC8DN1SkoWyy0umb36xQ0= X-Gm-Message-State: AOJu0YwDNX/ugvJ+USM2DFYGbjMSb1ZpUyinOWy361HxxBcDmeLofkoo 7mhsxOOyKQpwzenRLBUvvO07Gw7UKE2Fx78yQ9fI3HI03VdRdK4Ta3sQ0xjnVaaEohPsWotpitz hPcxYtwIhxitjQWugyRI66VAAFQ4= X-Google-Smtp-Source: AGHT+IG3Qs0+xfEueXgay/q0x75ZXaWOWC/3RP7WH7SqqyiLSOLlKrECWMc2rVaZGvh5qPUqqJBhFjmiwePw6P+eh6Y= X-Received: by 2002:a05:6122:2014:b0:4d4:11e9:c33f with SMTP id l20-20020a056122201400b004d411e9c33fmr596399vkd.5.1711070935188; Thu, 21 Mar 2024 18:28:55 -0700 (PDT) MIME-Version: 1.0 References: <20240314141516.31747-1-liuhailong@oppo.com> <20240315081803.2223-1-liuhailong@oppo.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 22 Mar 2024 14:28:44 +1300 Message-ID: Subject: Re: [PATCH v2] Revert "mm: skip CMA pages when they are not available" To: Michal Hocko 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A9616A000A X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: urni5oeog3t9s49dibscqidmdpz1so4b X-HE-Tag: 1711070936-667341 X-HE-Meta: U2FsdGVkX1+FDkm/BD5w/2OaM/WPeIBQfwzdaS/4qWumbFoqn2GC+hJ5cjc0qj4gCLsDbwS4wuQEVrxl9J2OoY7gzvn8QywD9IswQGH7xtbeFe6r7Bmw0cJbcan4pY7kMmKaB53M5dQj3DxA06nRCXzX2pOjEtBpB2iQtXaJRtHrEKHjNu/1J0t41oVor1+LUC/BB9mho8/PiN0t2VjvgE3n2C+wxD+XMQ9NKWNQ8YjnNEcMww6P3zIad3UDKt3oJKsDxi2MTXOWiAoPvh5DXadvusONL5jHZ7x9fKhz8qs57rwjrJShBqtlGyykuFIXWc20cONDGUhSAiHaN0SK15ZC9TEeUMqpktOTi3aojLl3fb9IQSjmFuwmVo+8c0doHBD0Mte65pl0iZLQ1fdUUxz1kmfbTzR5RXGUKt5u18USuQnqhMg7QsSDjTPXpWjAtkFUIFnP7nZjYWNSZL2Nw7AwZ/PBsIFCwuwNFJk6oM5stpNqXnU65sfskhII5tVzNMciUrYx5B6Pp3A7fDnST26L28Bb5uKFNRpbvkUws5fchyCdlaJi8YwUgV1eTcqzp08q7SOZUsKLceosYP39REFVr9mQVnUPSM71Y7fkHASQP1fL+z8xwfyioloAFDEF9IGjM55EVMtG3xp+tnuUC1HTUK7536nRxQsKlmxq0SEmwp/ej9dn2JZTpDN4teq6NX5LhVw5GBnfQVxD5vuxnYsAqk1a9cx1dn9hbUVECH7mdQPz95181F3HETND4+DqXM74otKV8OqL2Q2vtyEMlx+V9H7+CcasDqyxL4LpmlL/sYemp3ruQWRYzcS3Zx8fSm4jUQUE2Fd02CmG9G3eWRkNGVI1WLnqlifMwXqFl2M0tCEheMRNRWKpQs7hO3oo8fFAohR4OtaYEgXMP+xV8vJzfQbw/SDlHSHzhpVmboQzura7bLd4oZNK19weRfVY5T2BAqLE0L/PhSmJdrJ OL+hHtwc vBsaZ/pZNnhIZogr70pDKhvsIUzv6RgtesTOv 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 Wed, Mar 20, 2024 at 2:40=E2=80=AFAM Michal Hocko wrot= e: > > On Tue 19-03-24 19:09:18, Barry Song wrote: > > On Tue, Mar 19, 2024 at 4:56=E2=80=AFPM 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 n= ot eligible") > > > > commit 5da226dbfce3 ("mm: skip CMA pages when they are not availabl= e") > > > > > > > > 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 was= te > > > > 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 fi= le > > > > 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 a= ny > > > 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 LR= U > > without skip_cma()? > > No, I mean standard LRU reclaim implementation rather than MGLRU. I guess Hailong was running the standard LRU with active/inactive lists as his v1 even didn't touch MGLRU, https://lore.kernel.org/linux-mm/20240314141516.31747-1-liuhailong@oppo.com= / Hailong, please correct me if this is not the case. > > -- > Michal Hocko > SUSE Labs