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 27042C433F5 for ; Thu, 13 Jan 2022 09:25:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7171A6B00A0; Thu, 13 Jan 2022 04:25:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A0696B00A1; Thu, 13 Jan 2022 04:25:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 519C16B00A2; Thu, 13 Jan 2022 04:25:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0173.hostedemail.com [216.40.44.173]) by kanga.kvack.org (Postfix) with ESMTP id 3B60B6B00A0 for ; Thu, 13 Jan 2022 04:25:38 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E4CF4181BA3EF for ; Thu, 13 Jan 2022 09:25:37 +0000 (UTC) X-FDA: 79024731114.12.4911798 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by imf29.hostedemail.com (Postfix) with ESMTP id 2F3C6120004 for ; Thu, 13 Jan 2022 09:25:36 +0000 (UTC) Received: by mail-io1-f48.google.com with SMTP id h23so7544986iol.11 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=Yk7X2XKOwlJiBnkuhVX8hat8+XMr2AiCgSwnRRN4QnYwb7hHUg0TDl0BTsX15mDD0N O5x80a7y78DosHcGSwAunTjjyRY5ALdXe17o55cNIRrNt6l8zoh5jyTYx1aZhRXqek4f vjQGovqkwIoWqlfVekGctVGp3jltIn54g/85BkYGsbU5FYF2AOTz0YDkeS8ZtBWc5tcQ jt8T8dUHNMuwuayj9LCQRJIZCIxZ2AMkGwpMx6sykIe8+Li4EhMT5LQqG6OLVx2zL2L/ No6eUwLpDuHafSsemGyoH4Ia/AISt6W/ND9q3/Yw/CcZImhE4flJ6v3sFAQsAJOfdYRh RaFg== X-Gm-Message-State: AOAM530VGWH5SatuNJfnIw5eUHpltzzqoDy7RDdGIPPesR7JG2QI7/Mq NL5KFQWfQ4h8mZKih6yKnX0VJA== 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 2F3C6120004 X-Stat-Signature: dczmjuj7916ed9zm3wanmd11wc93zbkm Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KMAEG9zi; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yuzhao@google.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=yuzhao@google.com X-Rspamd-Server: rspam02 X-HE-Tag: 1642065936-640121 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 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.