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 DAA2FC433EF for ; Sat, 8 Jan 2022 00:19:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3781B6B0072; Fri, 7 Jan 2022 19:19:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FF716B0073; Fri, 7 Jan 2022 19:19:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A1BC6B0074; Fri, 7 Jan 2022 19:19:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0025.hostedemail.com [216.40.44.25]) by kanga.kvack.org (Postfix) with ESMTP id 04ABA6B0072 for ; Fri, 7 Jan 2022 19:19:35 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B88C597909 for ; Sat, 8 Jan 2022 00:19:34 +0000 (UTC) X-FDA: 79005211068.21.4A18CEF Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) by imf24.hostedemail.com (Postfix) with ESMTP id 609D2180006 for ; Sat, 8 Jan 2022 00:19:34 +0000 (UTC) Received: by mail-il1-f181.google.com with SMTP id o1so5726700ilo.6 for ; Fri, 07 Jan 2022 16:19:34 -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=U8P8SmP0qPdbiyx8lx3McbNzmYprIh1snsE0Jac/l90=; b=KlrSCUQ6zoHS28F0Wu1tDFI/yNUJ8ArVvaUy+uTlL/FeUDKBCOJYPtMyLINNBObFp4 YJ/EHx8ZtZ+S3b8u0YIKugkK9cmlbEod3BbXfucFCWP6ZzduECXW6Pkfy015WbnNuwpP jB/Dest13d5zIEhocs5RgEIniAQIpDBec6GHjTkBybmuKEpiXs5U/ignu8Zq+y3URSPh vFWB9tlWVyi1MpRHKGgcTY20bPrw1CKE7US7Gau6TVAqHyKg64DnrZQCY/tuvrNQdBYM qmcp58mJ61kqY3gwXNPlnOinlU8RG7OrfA7fQFpbbcavndFJlbgT6lc79ozILLgKkA/l 0n+w== 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=U8P8SmP0qPdbiyx8lx3McbNzmYprIh1snsE0Jac/l90=; b=m63xy/yzWh5B1CVE8Zk+OOErHkqmbCnB5SaNHgq5ieczsj5xoXLhPcix9IOUSOpt9i lKh1PpepEasHYnlwLrr1WfyToIIZRy+Z/uiGTF6pgRUFtaQTZvmxDwsYWiv0lm49iZTy 6lXjqny7zh2KNVAlmjyTDBfK/7oXZscCt/lfLsrxRH/C4VCTF33Mm7W7MHn4ei5MNaSK M7VACniSvlYhmuIwgPX/nRXZ1Oqi987aGzrwin99QNwuTVxO8Dg6n/7XUdAt6S8o40+6 qbUiTpizCs9SChuT2rlCOaQ4UsD8j9YdDVAkgIjPUQPria73WKjThvvMKLn0Las1zvFq GeGQ== X-Gm-Message-State: AOAM531u3B5k0dFOP+Hw4fzqADMWbLfkMMnSEn0MpCR5cOWISnqqRQGQ DZbU/Tvp1SBvSK6hWvGvgTLwxA== X-Google-Smtp-Source: ABdhPJzjBo4KzV0lFm0oheRxOqHhBQQ40kQO3JFbzrqyVzJYHo4OK2LeVQNGaPOUbBZTIP3KSFsvkA== X-Received: by 2002:a92:c744:: with SMTP id y4mr32084011ilp.124.1641601173525; Fri, 07 Jan 2022 16:19:33 -0800 (PST) Received: from google.com ([2620:15c:183:200:8b41:537d:f5d3:269c]) by smtp.gmail.com with ESMTPSA id s6sm90741ilq.21.2022.01.07.16.19.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Jan 2022 16:19:33 -0800 (PST) Date: Fri, 7 Jan 2022 17:19:28 -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 5/9] mm: multigenerational lru: mm_struct list Message-ID: References: <20220104202227.2903605-1-yuzhao@google.com> <20220104202227.2903605-6-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 609D2180006 X-Stat-Signature: h7typda896uokh6szxg3dira74ty9j13 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=KlrSCUQ6; spf=pass (imf24.hostedemail.com: domain of yuzhao@google.com designates 209.85.166.181 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1641601174-138090 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:06:15AM +0100, Michal Hocko wrote: > On Tue 04-01-22 13:22:24, Yu Zhao wrote: > > To exploit spatial locality, the aging prefers to walk page tables to > > search for young PTEs. And this patch paves the way for that. > > > > An mm_struct list is maintained for each memcg, and an mm_struct > > follows its owner task to the new memcg when this task is migrated. > > How does this work actually for the memcg reclaim? I can see you > lru_gen_migrate_mm on the task migration. My concern is, though, that > such a task leaves all the memory behind in the previous memcg (in > cgroup v2, in v1 you can opt in for charge migration). If you move the > mm to a new memcg then you age it somewhere where the memory is not > really consumed. There are two options to gather the accessed bit: page table walks and rmap walks. Page table walks sweep dense hotspots that are NOT misplaced in terms of reclaim scope (lruvec); rmap walks cover what page table walks miss, e.g., misplaced dense hotspots or sparse ones. Dense hotspots are stored in Bloom filters for each lruvec. If an mm leaves everything in the old memcg, page table walks in the new memcg reclaim path basically ignore this mm after the first scan, because everything is misplaced. In the old memcg reclaim path, page table walks won't see this mm at all. But rmap walks will catch everything later in the eviction path, i.e., lru_gen_look_around(). This function is less efficient compared with page table walks because, for each rmap walk of a non-shared page, it only can gather the accessed bit from 64 PTEs at most. But it's still a lot faster than the original rmap, which only gathers the accessed bit from a single PTE, for each walk of a non-shared page.