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 D3F57C433EF for ; Wed, 12 Jan 2022 01:03:00 +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=fNEtYntl4w2hkeqnU+Xg72Go58wePtj64Hy/Z8yrPlg=; b=1ek5ulKsXhTPXO slRwvB+uoqFCenvAKixiPFar4iIoInj9Tp39U0byxqjvLUCBDZPBizU7EgJjCTHn0PF4LeQu37P2z Ma3KUlsa53abHYTI7Po0t8/CZZpRrHIZHlNNIHJWtq3FsNTth8fND0qysUtqSirtzEnIZboPT6rUH xRIRCT+fTCU9h9k5ikHue3UPXH7C/jo3tenq+44jHQ+ALKA7Aysx7fmgY1eDETEctdNJ7vQmXuI0Y A84Qca74+VVOEy7jKA7MiOPprJw53HcK+WtWuHhnxqsIzP0qJFRaWnEBlFSuB501DthNBL8cEX45g waeKhxJ+WABSpAJ9hCPQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7S1D-000Z4Q-Ia; Wed, 12 Jan 2022 01:01:39 +0000 Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n7S19-000Z3J-En for linux-arm-kernel@lists.infradead.org; Wed, 12 Jan 2022 01:01:36 +0000 Received: by mail-io1-xd2b.google.com with SMTP id 19so1407867ioz.4 for ; Tue, 11 Jan 2022 17:01: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=jNmx8g8QULTnXgWyiPIunnbTModfNMXbNul38tS9+t8=; b=NAulvy+CL4jLdg6in4jpNyX7o1OXHQdkwuFvwX5K7RgDZTz13OcR7WH1DzcE9KdXbA nS7L/OR8QQxsClaVTxzf9z85k5DGUPK7XFCezMiE+490Ascv4a0eUEOWBTuv1nDuhdEa PHmeQ9GVNAa+ra/y7o7UcKabUURkxZ962JH1oMlEaPb0qwqwexHFud8ogggWGV0SCDC4 KAi0rVVB2AufTMb4+Ia2SPkN3jrhN28krE3UUjdvECd6LMIq4tvHOO61cuMaCe6V6RBr oL71D/7sN0O7wAfSrcaZurdbRBV7LcoPv2BEVpr10nte+y4wyG+7xGfDpqhxqv/KiPoN Wdjg== 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=jNmx8g8QULTnXgWyiPIunnbTModfNMXbNul38tS9+t8=; b=DJ2QXWsUL62Whvo7Ml1Dg4sl8vaEgVAp4Qn2CQjtKmn+SBT8M8tkQKlMZMJxmyNLUl WEzsiDu6aC7g5NPmlqwiVr9fN2nNtUzhIhrJt/vRGZJEPjHY93PGwe/p5dnr7FQ2fAfk gf0ezhfwnXiACrDTzvXEgfw/4Yfr7G/88PTMJ/ltbBBIhoTwJKOvN60568BVIDAJIw/X DCvYSdy4SxzOvO00WgzXyRDjry2/Xol8vqb+rqO9XXtMH7eWRlAuH3rZUk0zGTigp0CW Hb/TPA0MrHEW443yqNFUhzheM7lK/OFB8dI0nSXmkJLL55QMOUVxoJebSACtOXo9IEUX B4VQ== X-Gm-Message-State: AOAM530MU4ePmcQW9FGTIMeYPj9k0zGaUu4+R2UlYB+dC+pB5QLUNKuG x0CxoP9NfLIFcJTljS9w2WAOpg== X-Google-Smtp-Source: ABdhPJy6+Q9GpyROLohTnAHgRnpGuFaV485DidDlkI1AelSWNPEo/Rk4V8VZWl64qjBRxmXni7NRhA== X-Received: by 2002:a02:cc70:: with SMTP id j16mr2271558jaq.72.1641949294228; Tue, 11 Jan 2022 17:01:34 -0800 (PST) Received: from google.com ([2620:15c:183:200:b6b6:70f4:b540:6383]) by smtp.gmail.com with ESMTPSA id s6sm6758158ild.5.2022.01.11.17.01.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jan 2022 17:01:33 -0800 (PST) Date: Tue, 11 Jan 2022 18:01:29 -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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220111_170135_581017_952514F1 X-CRM114-Status: GOOD ( 16.11 ) 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 Mon, Jan 10, 2022 at 05:57:39PM +0100, Michal Hocko wrote: > On Tue 04-01-22 13:22:25, Yu Zhao wrote: > [...] > > +static void walk_mm(struct lruvec *lruvec, struct mm_struct *mm, struct lru_gen_mm_walk *walk) > > +{ > > + static const struct mm_walk_ops mm_walk_ops = { > > + .test_walk = should_skip_vma, > > + .p4d_entry = walk_pud_range, > > + }; > > + > > + int err; > > +#ifdef CONFIG_MEMCG > > + struct mem_cgroup *memcg = lruvec_memcg(lruvec); > > +#endif > > + > > + walk->next_addr = FIRST_USER_ADDRESS; > > + > > + do { > > + unsigned long start = walk->next_addr; > > + unsigned long end = mm->highest_vm_end; > > + > > + err = -EBUSY; > > + > > + rcu_read_lock(); > > +#ifdef CONFIG_MEMCG > > + if (memcg && atomic_read(&memcg->moving_account)) > > + goto contended; > > +#endif > > Why do you need to check for moving_account? This check, if succeeds, blocks memcg migration. Our goal is to move pages between different generations of the same lruvec (the first arg). Meanwhile, pages can also be migrated between different memcgs (different lruvecs). The active/inactive lru uses isolation to block memcg migration. Generations account pages similarly to the active/inactive lru, i.e., each generation has nr_pages counter. However, unlike the active/ inactive lru, a page can be moved to a different generation without getting isolated or even without being under the lru lock, as long as the delta is eventually accounted for (which does require the lru lock when it happens). The generation counter in page->flags (folio->flags to be precise) stores 0 when a page is isolated, to synchronize with isolation. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel