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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EEEAEC433F5 for ; Sat, 8 Jan 2022 00:21:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8Rl3wEWwqXs0BPKxIXVKc4m0ja+m/UDjgTvxF8xDImY=; b=tsqWhOdJPJ7FmU ecnoIyuXkFvXk9Qs7JbMc3sb6vq+f0T6o0O7J1PIDpYkzIa+Or+2UIYwUv3eijYDwXjs05rXHs815 HmqahFPHmFDNkNy7lriOwS0M0nwI7k+VdNmcicmuG1jhMGp8MZTDcdVnkeekizCg9G2Hl3rE0IP+g rm3gSRuxERZHOq9TOjFaeYbWAfWWlM5EAYBDnO24KMTGOY56ayVsGgslsHL+3/EJDomAJAY/f9cmg zl6pIieKkeCVIBZnn85fUXjsz23wFU1QUAcf6pxwYDsgV2wKFaRnWvKRc+25NA1a03NED9NfhmWs6 aDD9QsszVbYbyqK/xNYA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5zSM-005fPS-Ku; Sat, 08 Jan 2022 00:19:38 +0000 Received: from mail-il1-x132.google.com ([2607:f8b0:4864:20::132]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n5zSI-005fOH-Rf for linux-arm-kernel@lists.infradead.org; Sat, 08 Jan 2022 00:19:36 +0000 Received: by mail-il1-x132.google.com with SMTP id e8so5846798ilm.13 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=AHbyz+aHOUEK61RsK7IDXmY6FZx/fWsCODTwsMrhJamXJXDOaHOGbXTf7uDNXAw0w6 P9caDXDPOpTQL01VPQBUpriIYo/IlYnp6hEwjknEDTFx1tg2S3tMfo0ZpbHGhvN49ZLc HyMtxU9utHBQH7r8jDjD+3pNiF3udy5Xg8PB0aiQELR/ExWxVkmdpz+p/tHMaRxwzIBT 1tCWaEc1z52wNa62+gaMluaGzDy9TsNShFQc9EwdmtoI5OIPu3+RImwnm1s2S1G1NhY8 rt36045Px2WWqeEHCUP8gBcBOZaE4OOaipEpgc5iOheXsYrfRE0oEJpWXkVmhH7TsRtb dGew== X-Gm-Message-State: AOAM532dE9Qozgv88/L/as1OsX1DhBMyLoN8EiFD9CqsTtfpK3LXn8XZ Fjauz82j13Q/gAxRfm8CdwkUhQ== 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220107_161934_932907_B050E816 X-CRM114-Status: GOOD ( 19.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel