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 0AACAECAAD5 for ; Mon, 5 Sep 2022 09:26:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35285801CE; Mon, 5 Sep 2022 05:26:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DB578D0050; Mon, 5 Sep 2022 05:26:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17BA6801CE; Mon, 5 Sep 2022 05:26:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 064638D0050 for ; Mon, 5 Sep 2022 05:26:44 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CF57740CC2 for ; Mon, 5 Sep 2022 09:26:43 +0000 (UTC) X-FDA: 79877501886.19.DACEE0C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf27.hostedemail.com (Postfix) with ESMTP id 6953C400B2 for ; Mon, 5 Sep 2022 09:26:43 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 2E9C034E97; Mon, 5 Sep 2022 09:26:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1662370002; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=A8kMnmnEGb4e42SxoO/Da6t7aiL5oByguxcYDPvLWqc=; b=kuK7b0ryKFuxGuoMhxoUyORQGgCiC6SMlo9vNOEyeCmHfHSPBAdGZXbwqeBVUj/bmpmcb0 xcdVq8PuKmDt8fqtDO5mfEBPiUhcbga0HBrv5LZTIO2SoaO2RTVMmxZy6SmufJlmzg5gE5 NjLeQe0NWgLfxJv49RN96HONcf54TWU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1662370002; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=A8kMnmnEGb4e42SxoO/Da6t7aiL5oByguxcYDPvLWqc=; b=OqiOjocKbpIsFjA31WBkCDhf/Wm1q28253HfVNCDZJHCPp8Smk3rRxvPxb7Mj4TpuQ2Cjb wgtovb1IVqwaZnDA== Received: from suse.de (unknown [10.163.32.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 9F8CB2C145; Mon, 5 Sep 2022 09:26:40 +0000 (UTC) Date: Mon, 5 Sep 2022 10:26:38 +0100 From: Mel Gorman To: Wupeng Ma Cc: akpm@linux-foundation.org, david@redhat.com, ying.huang@intel.com, hannes@cmpxchg.org, corbet@lwn.net, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, songmuchun@bytedance.com, mike.kravetz@oracle.com, osalvador@suse.de, surenb@google.com, rppt@kernel.org, charante@codeaurora.org, jsavitz@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH -next v3 1/2] mm: Cap zone movable's min wmark to small value Message-ID: <20220905092619.2533krnnx632hswc@suse.de> References: <20220905032858.1462927-1-mawupeng1@huawei.com> <20220905032858.1462927-2-mawupeng1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20220905032858.1462927-2-mawupeng1@huawei.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662370003; a=rsa-sha256; cv=none; b=lVfj/qtOfZDzAB5Bf6TImXQ0yKS7199PZDRhP3pQoEUyq7YBoRKwRb1xjsS09WDmZTvAd6 5K9JuAb4CB2aNAvtwX/uo2ibZN4tzb2bOEofdTIqIEq+blhT7QTAGXmk/kp6VW3EcagvdU kAgLg/uTbSS00Wo/2DraTeNBAv4wANQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=kuK7b0ry; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=OqiOjocK; spf=pass (imf27.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662370003; 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=A8kMnmnEGb4e42SxoO/Da6t7aiL5oByguxcYDPvLWqc=; b=oYOLxhsZ9tiNViP/kTwhi/Sjha5D86kSJCjrd1H+x+5mCwbosQYxpd48XoIgJ+AS7SZ3G5 urIQk9m9x0Sc1PSziC/CWEAR0I4dFlfUnfrM/L5d0wuiDCv+Gj1mvbxK2rFu1bIjmUwX9i AI6NqqgKufl4wk2MygzaOi4Tfja8wW8= X-Stat-Signature: bhqaoht6n1ogjkbgxuhzpcae1fg9pxa4 X-Rspamd-Queue-Id: 6953C400B2 Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=kuK7b0ry; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=OqiOjocK; spf=pass (imf27.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.de; dmarc=pass (policy=none) header.from=suse.de X-Rspam-User: X-Rspamd-Server: rspam03 X-HE-Tag: 1662370003-506897 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 Mon, Sep 05, 2022 at 11:28:57AM +0800, Wupeng Ma wrote: > From: Ma Wupeng > > Since min_free_kbytes is based on gfp_zone(GFP_USER) which does not include > zone movable. However zone movable will get its min share in > __setup_per_zone_wmarks() which does not make any sense. > > And like highmem pages, __GFP_HIGH and PF_MEMALLOC allocations usually > don't need movable pages, so there is no need to assign min pages for zone > movable. > > Let's cap pages_min for zone movable to a small value here just link > highmem pages. > I think there is a misunderstanding why the higher zones have a watermark and why it might be large. It's not about a __GFP_HIGH or PF_MEMALLOC allocations because it's known that few of those allocations may be movable. It's because high memory allocations indirectly pin pages in lower zones. User-mapped memory allocated from ZONE_MOVABLE still needs page table pages allocated from a lower zone so there is a ratio between the size of ZONE_MOVABLE and lower zones that limits the total amount of memory that can be allocated. Similarly, file backed pages that may be allocated from ZONE_MOVABLE still requires pages from lower memory for the inode and other associated kernel objects that are allocated from lower zones. The intent behind the higher zones having a large min watermark is so that kswapd reclaims pages from there first to *potentially* release pages from lower memory. By capping pages_min for zone_movable, there is the potential for lower memory pressure to be higher and to reach a point where a ZONE_MOVABLE page cannot be allocated simply because there isn't enough low memory available. Once the lower zones are all unreclaimable (e.g. page table pages or the movable pages are not been reclaimed to free the associated kernel structures), the system goes OOM. It's possible that there are safe adjustments that could be made that would detect when there is no choice except to reclaim zone reclaimable but it would be tricky and it's not this patch. This patch changelog states However zone movable will get its min share in __setup_per_zone_wmarks() which does not make any sense. It makes sense, higher zones allocations indirectly pin pages in lower zones and there is a bias in reclaim to free the higher zone pages first on the *possibility* that lower zone pages get indirectly released later. -- Mel Gorman SUSE Labs