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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2FB5AC38142 for ; Fri, 27 Jan 2023 08:57:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=nHEhN4B14no2mRhnXzOOFljbfLopE6vDQztGGjCinV8=; b=4yJFLy5f02Lj/l mTkf618xM1ihMEOh9WaPAiqHoeb9u9BN4mUCX2q+/qjB9gUaM188OKp9Bz3slIJiUylL+LwZ1+3Jk g8WCvP/FW6DZoDut6Vq3FZOZJoDT/dzAz5ohPrV1NabMX8BxHkn/gevmj87wjNheh2eUiyCi61nc4 JAk9jJzq9MaAWOvXYYRXCVOWXpZXWhGKcMsPo/ClYTPj8SAQSsN4tH83XcGLxqieU0ks4mFH6+fjH GAiYZnGJoCnPjp8SUC58oUU2dLk4r0CtJgJdm4O9QX+6EMHKNs6a6Ipx560oWpgostWyE5VPy/tbP RsKvH4rjvaTo8BbHnS1Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pLKXa-00DZ1K-7k; Fri, 27 Jan 2023 08:56:58 +0000 Received: from r3-20.sinamail.sina.com.cn ([202.108.3.20]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pLKXV-00DYzJ-FC for linux-arm-kernel@lists.infradead.org; Fri, 27 Jan 2023 08:56:56 +0000 Received: from unknown (HELO localhost.localdomain)([114.249.61.130]) by sina.com (172.16.97.35) with ESMTP id 63D390C600034FB0; Fri, 27 Jan 2023 16:52:24 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 68793615073583 From: Hillf Danton To: Chris Goldsworthy Cc: Robin Murphy , dave.hansen@linux.intel.com, bp@alien8.de, hpa@zytor.com, hch@lst.de, m.szyprowski@samsung.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, djakov@kernel.org Subject: Re: [RFC] mm: Allow ZONE_DMA32 to be disabled via kernel command line Date: Fri, 27 Jan 2023 16:55:53 +0800 Message-Id: <20230127085553.5120-1-hdanton@sina.com> In-Reply-To: <20230127021348.GA3754@hu-cgoldswo-sd.qualcomm.com> References: <20230126164352.17562-1-quic_c_gdjako@quicinc.com> <555fca66-81b6-3406-eac1-140c00669477@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230127_005653_768265_7E01A5E0 X-CRM114-Status: GOOD ( 27.05 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 26 Jan 2023 18:20:26 -0800 Chris Goldsworthy > On Thu, Jan 26, 2023 at 07:15:26PM +0000, Robin Murphy wrote: > > On 2023-01-26 16:43, Georgi Djakov wrote: > > >From: Chris Goldsworthy > > > > > >It's useful to have an option to disable the ZONE_DMA32 during boot as > > >CONFIG_ZONE_DMA32 is by default enabled (on multiplatform kernels for > > >example). There are platforms that do not use this zone and in some high > > >memory pressure scenarios this would help on easing kswapd (to leave file > > >backed memory intact / unreclaimed). When the ZONE_DMA32 is enabled on > > >these platforms - kswapd is woken up more easily and drains the file cache > > >which leads to some performance issues. > > > > > >Signed-off-by: Chris Goldsworthy > > >[georgi: updated commit text] > > >Signed-off-by: Georgi Djakov > > >--- > > >The main question here is whether we can have a kernel command line > > >option to disable CONFIG_ZONE_DMA32 during boot (at least on arm64). > > >I can imagine this being useful also for Linux distros. > > > > FWIW I'd say that "disabled" and "left empty then awkwardly tiptoed around > > in a few places" are very different notions... > > > > However, I'm just going to take a step back and read the commit message a > > few more times... Given what it claims, I can't help but ask why wouldn't we > > want a parameter to control kswapd's behaviour and address that issue > > directly, rather than a massive hammer that breaks everyone allocating > > explicitly or implicitly with __GFP_DMA32 (especially on systems where it > > doesn't normally matter because all memory is below 4GB anyway), just to > > achieve one rather niche side-effect? > > > > Thanks, > > Robin. > > Hi Robin, > > The commit text doesn't spell out the scenario we want to avoid, so I > will do that for clarity. We use a kernel binary compiled for us, and > by default has CONFIG_ZONE_DMA32 (and it can't be disabled for now as > another party needs it). Our higher-end SoCs are usually used with > 8-12 GB of DDR, so using a 12 GB device as an example, we would have 8 > GB of ZONE_NORMAL memory and 4 GB of ZONE_MOVABLE memory with the > feature, and 4 GB of ZONE_DMA32, 4 GB of ZONE_NORMAL and 4 GB of > ZONE_MOVABLE otherwise. > > Without the feature enabled, consider a GFP_KERNEL allocation that > causes a low watermark beach in ZONE_NORMAL, such that such that > ZONE_DMA32 is almost full. This will cause kswapd to start reclaiming > memory, despite the fact that that we might have gigabytes of free > memory in ZONE_DMA32 that can be used by anyone (since GFP_MOVABLE and > GFP_NORMAL can fall back to using ZONE_DMA32). If kswapd is busy reclaiming pages even given gigabytes of free memory in the DMA32 zone then it is a CPU hog. Feel free to check pgdat_balanced() and prepare_kswapd_sleep(). > > So, fleshing out your suggestion to make it concrete for our case, we > would want to stop kswapd from doing reclaim on ZONE_NORMAL watermark > breaches when ZONE_DMA32 is present (since anything targeting > ZONE_NORMAL can fall back to ZONE_DMA32). > > Thanks, > > Chris. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel