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 659BDC43217 for ; Tue, 7 Dec 2021 01:24:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9D8E36B0085; Mon, 6 Dec 2021 20:23:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 98A446B0087; Mon, 6 Dec 2021 20:23:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 877BF6B0088; Mon, 6 Dec 2021 20:23:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id 79BE66B0085 for ; Mon, 6 Dec 2021 20:23:56 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3C6701809AC4F for ; Tue, 7 Dec 2021 01:23:46 +0000 (UTC) X-FDA: 78889251252.10.B4B9DDB Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf30.hostedemail.com (Postfix) with ESMTP id C30D4E0016A1 for ; Tue, 7 Dec 2021 01:23:45 +0000 (UTC) Received: from mail.kernel.org (unknown [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DA45CB81607; Tue, 7 Dec 2021 01:23:43 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id E6DC460E09; Tue, 7 Dec 2021 01:23:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1638840222; bh=jG8jLRpDxgN2xvF5ecWxhh9KjD9YifxAcaT6H/zTPVA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=WS8/GJmkzTqLpQGK3js6E3UYS/N8YQexO2PLCCaYPNV/CFkfl1KfYuyNW2O+wUfTV /Fe+Ivf2yUuv6lBlMyRowe7/Fo3c+6H+YKDaI3ihT3RbX1SDQ2/ozPsJp9cPRySRjA +b0bulQdTuqHmt2azMFxCfTM7BND10cTuMlt0G/4= Date: Mon, 6 Dec 2021 17:23:40 -0800 From: Andrew Morton To: Huangzhaoyang Cc: Zhaoyang Huang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-cachefs@redhat.com, David Howells Subject: Re: [PATCH] mm: mask DIRECT_RECLAIM in kswapd Message-Id: <20211206172340.fded3873aed7e853b54ab276@linux-foundation.org> In-Reply-To: <1638760762-27239-1-git-send-email-huangzhaoyang@gmail.com> References: <1638760762-27239-1-git-send-email-huangzhaoyang@gmail.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C30D4E0016A1 X-Stat-Signature: jmu7hi46xdy43m5m4nr91yw9xh3tmha7 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="WS8/GJmk"; spf=pass (imf30.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1638840225-78858 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, 6 Dec 2021 11:19:22 +0800 Huangzhaoyang wrote: > From: Zhaoyang Huang > > As the eg bellowing, using GFP_KERNEL could confuse the registered .releasepage > or .shrinker functions when called in kswapd and have them acting wrongly.Mask > __GFP_DIRECT_RECLAIM in kswapd. > > eg, > kswapd > shrink_page_list > try_to_release_page > __fscache_maybe_release_page > ... > if (!(gfp & __GFP_DIRECT_RECLAIM) || !(gfp & __GFP_FS)) { > fscache_stat(&fscache_n_store_vmscan_busy); > return false; > } Well, we have thus far been permitting kswapd's memory allocations to enter direct reclaim. Forbidding that kernel-wide might be the right thing to do, or might not be. But disabling it kernel-wide because of a peculiar hack in fscache is not good justification. > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -4083,7 +4083,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int highest_zoneidx) > bool boosted; > struct zone *zone; > struct scan_control sc = { > - .gfp_mask = GFP_KERNEL, > + .gfp_mask = GFP_KERNEL & ~__GFP_DIRECT_RECLAIM, > .order = order, > .may_unmap = 1, > }; Maybe hack the hack like this? --- a/fs/fscache/page.c~a +++ a/fs/fscache/page.c @@ -126,8 +126,10 @@ page_busy: * sleeping on memory allocation, so we may need to impose a timeout * too. */ if (!(gfp & __GFP_DIRECT_RECLAIM) || !(gfp & __GFP_FS)) { - fscache_stat(&fscache_n_store_vmscan_busy); - return false; + if (!current_is_kswapd()) { + fscache_stat(&fscache_n_store_vmscan_busy); + return false; + } } fscache_stat(&fscache_n_store_vmscan_wait); _ But please, do cc the fscache mailing list and maintainer when mucking with these things.