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 79863C433F5 for ; Wed, 19 Jan 2022 09:44:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C88246B0071; Wed, 19 Jan 2022 04:44:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C37CC6B0073; Wed, 19 Jan 2022 04:44:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B263A6B0074; Wed, 19 Jan 2022 04:44:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id A1B866B0071 for ; Wed, 19 Jan 2022 04:44:23 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 66CBC824C45C for ; Wed, 19 Jan 2022 09:44:23 +0000 (UTC) X-FDA: 79046551206.26.0D88521 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf11.hostedemail.com (Postfix) with ESMTP id F21584000F for ; Wed, 19 Jan 2022 09:44:22 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 040BC218B1; Wed, 19 Jan 2022 09:44:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1642585462; 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=wd3d1acncrN3IVV5mgX/L/jJbqedR5eFN/1PmkMkzAg=; b=Kdg2KeeNAASnM5cZJcAIdy1LlLKxEhnP795ZWM/tTUl0SuDKuXKu07ycmgfMZP4eVMdt/8 hpTrsN+B6Qmr7E79NcMHHeXOsBAYUaHIJmTRW4xNlmLl6Bd10zA9wrSEzBVAuISXaJ4nsD auQfHN9ea7Nv7WOWSEnm8oZyZY9sCHs= 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 92218A3BA7; Wed, 19 Jan 2022 09:44:21 +0000 (UTC) Date: Wed, 19 Jan 2022 10:44:21 +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-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: F21584000F X-Stat-Signature: b787tx4hodwmn75f8dd6awrj6m468az1 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Kdg2KeeN; spf=pass (imf11.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: 1642585462-191907 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 Tue 18-01-22 23:31:07, Yu Zhao wrote: > On Thu, Jan 13, 2022 at 01:02:26PM +0100, Michal Hocko wrote: > > 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. > > Thanks. I'll change GFP_KERNEL to __GFP_HIGH | __GFP_NOMEMALLOC. > __GFP_HIGH allows some access to memory reserves and __GFP_NOMEMALLOC > prevents the complete depletion. Basically the combination lower the > min watermark by 1/2, and we have been using them for > add_to_swap_cache(). Yes this will prevent the complete memory depletion. There are other users of this portion of memory reserves so the reclaim might be out of luck. How this turns out in practice remains to be seen though but it certainly is an opportunity for corner cases and hard to test behavior. -- Michal Hocko SUSE Labs