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 6BE6EC433FE for ; Thu, 13 Jan 2022 12:02:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECAFD6B008A; Thu, 13 Jan 2022 07:02:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7B446B008C; Thu, 13 Jan 2022 07:02:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6A3C6B0092; Thu, 13 Jan 2022 07:02:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id C8F446B008A for ; Thu, 13 Jan 2022 07:02:33 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1B4E89369D for ; Thu, 13 Jan 2022 12:02:33 +0000 (UTC) X-FDA: 79025126586.21.3FAEECE Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf17.hostedemail.com (Postfix) with ESMTP id 7A0F74000E for ; Thu, 13 Jan 2022 12:02:28 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5EA34210E8; Thu, 13 Jan 2022 12:02:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1642075347; 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=LZVuyyTRSpRE6S8FOnrto8JpNJcnle8TpJ/IrQ16lRc=; b=keRZklNq4LxORySqWTBm2nBLk9YWgDGDuwL/AQ+Mai2k802cEBoIYsNa3oXRyNH0HTIcwI V0Cx9P6UsQ3SnsnAARYqz2HSalqMY0kXU8ZFunLpj8tmOa6xB7yoJbMInasHRJzL0REQLn mjW8NuZF0+swe/oGVE1356UI19oPou0= Received: from suse.cz (unknown [10.100.201.86]) (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 E510FA3B87; Thu, 13 Jan 2022 12:02:26 +0000 (UTC) Date: Thu, 13 Jan 2022 13:02:26 +0100 From: Michal Hocko To: Yu Zhao 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-Server: rspam01 X-Rspamd-Queue-Id: 7A0F74000E X-Stat-Signature: hf66tcn7wajcr7zfgwmrdosiyzh1xuuo Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=keRZklNq; spf=pass (imf17.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1642075348-234691 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 Thu 13-01-22 02:43:38, Yu Zhao wrote: [...] > > > The bottom line is I can try various optimizations, e.g., preallocate > > > a few buffers for a limited number of page walkers and if this number > > > has been reached, fallback to the rmap-based function. But I have yet > > > to see evidence that calls for additional complexity. > > > > I would disagree here. This is not an optimization. You should be > > avoiding allocations from the memory reclaim because any allocation just > > add a runtime behavior complexity and potential corner cases. > > Would __GFP_NOMEMALLOC address your concern? It prevents allocations > from accessing the reserves even under PF_MEMALLOC. __GFP_NOMEMALLOC would deal with the complete memory depletion concern for sure but I am not sure how any of these allocations would succeed when called from the direct reclaim. Some access to memory reserves is necessary if you insist on allocating from the reclaim process. You can have a look at the limited memory reserves access by oom victims for an example of how this can be done. -- Michal Hocko SUSE Labs