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 37312C433F5 for ; Thu, 13 Jan 2022 09:26:58 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hen8yOpc7f5gPqDzIHEkrtDrJh1tYgk4HeGevaWZuaY=; b=u0McJ9DqguqcrA GDc+1zEZdwjpf4wEsTW2eadHDnQmPcTtFKp5iFm3gSyDUm6xtJFQn04i4sqEOYJWLtMJn3yiC+1Jt uGZl47G33Qi8jkaoEiJrHGJmpcUVXqD7q2Vbk+tAhvKYNZMRJilXVgzC+cfSeBBMcZ/61b/rZHciC ZBJDsc3DzZzsGrnJkSKekTYeTKfMpzYHJADPTYUJ99rAe6iAuVigsnRRxBIHTZWIP+gwMmzs+0GUD NH+KA6S4LtPGstC7q7blWRUZle4HHSBFRd1wEFU4HLihqEZ1xW3CcmFvXuF+2Iphrd9f2rLWe7cDy t1kgDsveBb6X27ueyFsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7wMV-005GVJ-Nk; Thu, 13 Jan 2022 09:25:39 +0000 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7wMS-005GTe-Nf for linux-arm-kernel@lists.infradead.org; Thu, 13 Jan 2022 09:25:38 +0000 Received: by mail-io1-xd2a.google.com with SMTP id e16so513339iob.12 for ; Thu, 13 Jan 2022 01:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=buO1MWlrsiI4ThiE8ebM/qEepT6gBkUde7jyQkyjwsk=; b=KMAEG9ziKENxPP1OUvgV8H9b9riW0zf1s8l6B8uIy7wERxSV6hUC7vq3U5MlfoI6SZ hiSVecAggVpDg6qiv5KFgTnfy7Czx0NQA/RaFx5G1DaUMLKMliLi916tEEesAq6vHJaE YGLSdVuRxoJGBBWUzrLdilBviof2yDJjhzavjFJawr11Nt7WhL/omEZ7LjA/7Q3+udtG bjJIrtPHwC66r3gB18NPzQEttfS7SKkOHYiBZdsjIACvA2WdLSqswqepyseE1KYgd4Oi 4cJIyV8BaKn1Oi07itiSTJxh/yIJbeuP6tRmHWUfnzSyAAeDldkgqO25AknZu+VRbPGM bA1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=buO1MWlrsiI4ThiE8ebM/qEepT6gBkUde7jyQkyjwsk=; b=aK68XmaS8Zl4Q89fcDRSewJdTpimL0ny9cp89+geUsJZop091qi6MJ/B3VpXlkIrap Js91jUzi1lO5PsoyuTxVv59d2a203Qyi8WNDxMaSw6wGeGdhagvg2U4pqPpwm8sCaqto b86h/xApM2xfPkkjAwYQ3oX4AsMIew/to8e+y88eA5Hen/G//Ax4i/D8QyHWy+xqHw69 IB9cSASwJROvqGzLAHa+6qeEXdvlBm/A1NEhN2vPF02ImFzzoAFZBjAKiBLOoruMczf7 h+Og5+RRmmdx6oMhR8TovSl7kjmTq4Si3wyCA9+0Q4frbBjpQ4j8Bryg/bkIFPSjWNER EIpQ== X-Gm-Message-State: AOAM533PT9PDzfbNTMev5loVC8xtj91eb1PoKcLprVF5XGim3p8ALzYX Ln4A1e4BZAJ3A5g4lXKsrcLCFQ== X-Google-Smtp-Source: ABdhPJxpdfdhJM+DmhBp7LTkz0JGkOoR+uvxcCvDtUCxvIxN1P5mrcrBrzRFrIMyX49jOdAeRASeog== X-Received: by 2002:a05:6638:2246:: with SMTP id m6mr1626108jas.292.1642065935899; Thu, 13 Jan 2022 01:25:35 -0800 (PST) Received: from google.com ([2620:15c:183:200:ac2b:c4ef:2b56:374c]) by smtp.gmail.com with ESMTPSA id b17sm2192509iow.6.2022.01.13.01.25.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jan 2022 01:25:35 -0800 (PST) Date: Thu, 13 Jan 2022 02:25:31 -0700 From: Yu Zhao To: Michal Hocko Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, page-reclaim@google.com, x86@kernel.org, Konstantin Kharlamov Subject: Re: [PATCH v6 6/9] mm: multigenerational lru: aging Message-ID: References: <20220104202227.2903605-1-yuzhao@google.com> <20220104202227.2903605-7-yuzhao@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220113_012536_812446_6145AD50 X-CRM114-Status: GOOD ( 18.26 ) 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 Wed, Jan 12, 2022 at 11:28:57AM +0100, Michal Hocko wrote: > On Tue 11-01-22 16:16:57, Yu Zhao wrote: > > On Mon, Jan 10, 2022 at 04:01:13PM +0100, Michal Hocko wrote: > > > On Thu 06-01-22 17:12:18, Michal Hocko wrote: > > > > On Tue 04-01-22 13:22:25, Yu Zhao wrote: > > > > > +static struct lru_gen_mm_walk *alloc_mm_walk(void) > > > > > +{ > > > > > + if (!current->reclaim_state || !current->reclaim_state->mm_walk) > > > > > + return kvzalloc(sizeof(struct lru_gen_mm_walk), GFP_KERNEL); > > > > > > One thing I have overlooked completely. > > > > I appreciate your attention to details but GFP_KERNEL is legit in the > > reclaim path. It's been used many years in our production, e.g., > > page reclaim > > swap_writepage() > > frontswap_store() > > zswap_frontswap_store() > > zswap_entry_cache_alloc(GFP_KERNEL) > > > > (And I always test my changes with lockdep, kasan, DEBUG_VM, etc., no > > warnings ever seen from using GFP_KERNEL in the reclaim path.) > > OK, I can see it now. __need_reclaim will check for PF_MEMALLOC and skip > the fs_reclaim tracking. > > I still maintain I am not really happy about (nor in the zswap example) > allocations from the direct reclaim context. I would really recommend > using a pre-allocated pool of objects. Not trying to argue anything -- there are many other places in the reclaim path that must allocate memory to make progress, e.g., add_to_swap_cache() xas_nomem() __swap_writepage() bio_alloc() The only way to not allocate memory is drop clean pages. Writing dirty pages (not swap) might require allocations as well. (But we only write dirty pages in kswapd, not in the direct reclaim path.) > If there are strong reasons for not doing so then at lease change that > to kzalloc. Consider it done. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel