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 17C72C433F5 for ; Mon, 10 Jan 2022 03:58:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7AE7E6B0071; Sun, 9 Jan 2022 22:58:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75E066B0073; Sun, 9 Jan 2022 22:58:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64D8C6B0074; Sun, 9 Jan 2022 22:58:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0201.hostedemail.com [216.40.44.201]) by kanga.kvack.org (Postfix) with ESMTP id 56BA36B0071 for ; Sun, 9 Jan 2022 22:58:08 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0ABC5824C421 for ; Mon, 10 Jan 2022 03:58:08 +0000 (UTC) X-FDA: 79013019456.08.8C4A1AE Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by imf25.hostedemail.com (Postfix) with ESMTP id AFE08A0008 for ; Mon, 10 Jan 2022 03:58:07 +0000 (UTC) Received: by mail-io1-f49.google.com with SMTP id y18so15861111iob.8 for ; Sun, 09 Jan 2022 19:58:07 -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=KxSZiZRQdqgzdFlRO54VlTYfuoCWD/E1gz0LmgTtY38=; b=REoii0frtVOfZhhAxIh91rJdHCGK7bn45fqrjPAxVpQymjoFztAMtMZT0KcktH3hRh 01aHhky4dPCdWvQTdWvrpXnUFvQ4QC+xYCMJN01V+uu5/FKRFI6gDxLvulQX6cOqZOfh Cjs+QR2qzbEiYQfMFE8OCh7ApgufOuAqP2NBJgz4JcskpiDNfsjADISE0VvJxpl40/li whaTVnRIvCvYKkjVnEHI/HmUKm1HVIQXB3m1N9DeQAcvYaTpQ3HjtMa30tqp3n2ozp4/ CtOYHvutdoUuynzRQXPt6nKPvX52HPvW2X+QvHu7NCUOTUuWVhOGoz/0G6KEcTm4ILse e0OA== 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=KxSZiZRQdqgzdFlRO54VlTYfuoCWD/E1gz0LmgTtY38=; b=BbH2YiSKhTS0tSHvjxaRbPbZ5ILNqnmBooo8p2tcD+pyCmJu/EDUn9FVKlRNufSnah QLkdhsbhv8MgkDoSWpRMr6OE1g+++GqUfU0fZ0vB2WLPEo6EGsrl42dRx5iqG++6inID ZAWFWOF4hxcPYMPxf5WRlpynkXiqHb6Hrf4xhmZOMsaw2A/11/a7S8u+CSFoF76d1REg 3IocZUIhTGJvz2DUoEWCTI+4TTxSkGH8veYimy7slJItopT2CUX8i3wnkmqiHHfGlUnv k4QhC4isgagcwmaPQ8MMpBviWCrWMBL+/dkom7InCXt2t6X7y8JsmvKWCvWWP7RidW6W FQrA== X-Gm-Message-State: AOAM533O4K7pTRp+PqXDn8XnQX4LBsHihbUsuFejaVxMs5u1djNOi6E3 oEDMM6SPv4mZ8NXR86XXccW2Pg== X-Google-Smtp-Source: ABdhPJz7TEYmMxMwyDgcG8hn/K2tGWPANlpL5C2Rd+UacwgE3SCcvv0POx4pvE+v0p2KoHgDYwDDKg== X-Received: by 2002:a02:3342:: with SMTP id k2mr25038656jak.231.1641787086863; Sun, 09 Jan 2022 19:58:06 -0800 (PST) Received: from google.com ([2620:15c:183:200:d17d:9fe6:6a18:f270]) by smtp.gmail.com with ESMTPSA id d11sm3582345ilv.6.2022.01.09.19.58.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Jan 2022 19:58:06 -0800 (PST) Date: Sun, 9 Jan 2022 20:58:02 -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: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=REoii0fr; spf=pass (imf25.hostedemail.com: domain of yuzhao@google.com designates 209.85.166.49 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Queue-Id: AFE08A0008 X-Stat-Signature: nfu3yepfjjd8fw6jnb8ysptuyzz61dfc X-Rspamd-Server: rspam04 X-HE-Tag: 1641787087-121491 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 Fri, Jan 07, 2022 at 10:00:31AM +0100, Michal Hocko wrote: > On Fri 07-01-22 09:55:09, Michal Hocko wrote: > [...] > > > In this case, lru_gen_mm_walk is small (160 bytes); it's per direct > > > reclaimer; and direct reclaimers rarely come here, i.e., only when > > > kswapd can't keep up in terms of the aging, which is similar to the > > > condition where the inactive list is empty for the active/inactive > > > lru. > > > > Well, this is not a strong argument to be honest. Kswapd being stuck > > and the majority of the reclaim being done in the direct reclaim > > context is a situation I have seen many many times. > > Also do not forget that memcg reclaim is effectivelly only direct > reclaim. Not that the memcg reclaim indicates a global memory shortage > but it can add up and race with the global reclaim as well. I don't dispute any of the above, and I probably don't like this code more than you do. But let's not forget the purposes of PF_MEMALLOC, besides preventing recursive reclaims, include letting reclaim dip into reserves so that it can make more free memory. So I think it's acceptable if the following conditions are met: 1. The allocation size is small. 2. The number of allocations is bounded. 3. Its failure doesn't stall reclaim. And it'd be nice if 4. The allocation happens rarely, e.g., slow path only. The code in question meets all of them. 1. This allocation is 160 bytes. 2. It's bounded by the number of page table walkers which, in the worst, is same as the number of mm_struct's. 3. Most importantly, its failure doesn't stall the aging. The aging will fallback to the rmap-based function lru_gen_look_around(). But this function only gathers the accessed bit from at most 64 PTEs, meaning it's less efficient (retains ~80% performance gains). 4. This allocation is rare, i.e., only when the aging is required, which is similar to the low inactive case for the active/inactive lru. 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.