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 29B29C433F5 for ; Thu, 13 Jan 2022 11:57:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77DC06B0088; Thu, 13 Jan 2022 06:57:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 72D9B6B0089; Thu, 13 Jan 2022 06:57:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F5B56B008A; Thu, 13 Jan 2022 06:57:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 514486B0088 for ; Thu, 13 Jan 2022 06:57:42 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 098CF93D96 for ; Thu, 13 Jan 2022 11:57:42 +0000 (UTC) X-FDA: 79025114364.17.527C1AF Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf16.hostedemail.com (Postfix) with ESMTP id 94A03180007 for ; Thu, 13 Jan 2022 11:57:41 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 2D1721F3A5; Thu, 13 Jan 2022 11:57:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1642075060; 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=lewmpLo/LsNms+2qW30Nngxyo9/rk6CzvqYO8ieYnV8=; b=LVNTyLA6AWr4vMsxHfrm31Uc801ybPFJp4QiLY7el8++BGBNnjG8uqvk9ZzcXSqLwvewub buqU8bGiyVwsBWUKF2oQUvULUsLUay9xZAj+QDz5SbHw4jL44Qga5MnjpeTdSLkCj7HBTt Cupf5Ta/1iyHX0cGnEYui8DW4BX5onI= 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 3521EA3B88; Thu, 13 Jan 2022 11:57:39 +0000 (UTC) Date: Thu, 13 Jan 2022 12:57:35 +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-Stat-Signature: 99kafd8ngspf7wyaf9y5z89wdmezfzsf Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=LVNTyLA6; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 94A03180007 X-HE-Tag: 1642075061-444816 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 12-01-22 16:43:15, Yu Zhao wrote: > On Wed, Jan 12, 2022 at 11:17:53AM +0100, Michal Hocko wrote: [...] > > Is there any reason you are not using folio_memcg_lock in the > > pte walk instead? > > We have a particular lruvec (the first arg), hence a particular memcg > to lock. But we don't have a particular page to lock. That is certainly true at this layer but the locking should be needed only for specific pages, no? So you can move the lock down to the callback which examines respective pages. Or is there anything preventing that? To be honest, and that is the reason I am asking, I really do not like to open code the migration synchronization outside of the memcg proper. Code paths which need a stable memcg are supposed to be using folio_memcg_lock for the specific examination time. If you prefer a trylock approach for this usecase then we can add one. -- Michal Hocko SUSE Labs