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 C4FCEC433F5 for ; Mon, 10 Jan 2022 04:50:38 +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=OdU8hk2tu5bRNbfpJ8TUWmKVTs8GWdbxGMTcPFv+CwU=; b=mmGV/x8ZAg7j3r lbTdBAfwtBU22kT4Vmw7R3y/VA9p4fIO+PKp+VFL9PP5i7Cc+oNUI+mDow0TdAHUqIlFGztUuhyNQ EarRrKXzPvwA2UCLImHkbTVEeXdCRt15xmSucow22c9XGP/Tnxh84GV1KrxvPtzvnIlhXLro7XBya v4dLfMt5J8I5r54zYm3Ebbm9JuE515/FUNSIE1Jo1V3er9ZzGYsjMgas2uTJs8HtE9Nf6+1az+4zZ s3aQuQwOdNSuhRgY6RhKUxuu8KZTBHqwP+Pkic7H3JattwTjg/rHUNf72cm3EJ5UbpG2Wi7w/QMpG fRDH0Jfv4BNyadiLcDsg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n6mbI-009Eya-Ou; Mon, 10 Jan 2022 04:48:08 +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 1n6mbE-009ExD-HO for linux-arm-kernel@lists.infradead.org; Mon, 10 Jan 2022 04:48:06 +0000 Received: by mail-io1-xd2b.google.com with SMTP id w22so5446272iov.3 for ; Sun, 09 Jan 2022 20:48:04 -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=guDTMY1gDKbuEeHSjJBqpytUvSIpcoxzveWlee08C0k=; b=cLjKHl/ZssXUW2pXxDtVnoKKLcr+3KmiIUZANhNj1odZoOSUuOnEcRUk3/GzhfwX9l I2d55GavHG9UBfE9O7qOBDicVTSC3VgU2oQzb74lP7ThokGz0p61MCDol/m5Y5ZKu9pn SVpDBX5LfcNJDDUn4yyS2cdlmaI78ysmlsvuyWQzxsievAshuB6rWKX8DHp92ldMt3zY B4ne5V6CrxYJGLdzok22NDcHnJ888zHEEYrF3wi5/SWDuDbeFyaUPN56nH0Ld2N46MwE f6ZAH1f8EYlHkNc4dNQ1swga9w9EtS1u5p3L8IVZA4FMXKGSjfCsGVu19Qu2Vzzx9+vI LTBA== 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=guDTMY1gDKbuEeHSjJBqpytUvSIpcoxzveWlee08C0k=; b=1OhISs6KNMdjok8eVPEX/6OuV9oOBzch47QonNzfMiB5IwFAGB6wfx7+RfcmP6hfbj 9KX9oJgKHrOUizVaPNgTj8DkXcW65ugIsP7Ntn7nJxoj8mpH29N0NyvDl/He2G75ukqI USSFCdpXJsG2ZkOzaSZ4y9EkQEDmdiGQy8fm+VHRUg7tyjwpySGz84YeuBqSckorlhkD LlFLAznyX7My84NlCZZZ5Rukr71TAlNmtQAg1tDUnUChhT1ZdbqC4de66+iyW2osv5fh bczRiIGfBPSs2YtZiUL9Y5AAuqdBJvVW6pVcRGS0E0hVwlbxiTg9rLDa4sY6b64adUng T4gQ== X-Gm-Message-State: AOAM532NgzORx2l1YJZYV+NJZeSd3+/ULUNUspbNTs3AmhOI7l4G6CyZ frBdzfEMWpPbI0WhNm+ccrheTA== X-Google-Smtp-Source: ABdhPJxFUbrC0ZIhFKmqo908OFMH2pxK5vT/Vqqp8hKFWDmgoGpLXOANCv2QbMHi2EceqWLqE78zrg== X-Received: by 2002:a05:6638:4192:: with SMTP id az18mr34204838jab.252.1641790083298; Sun, 09 Jan 2022 20:48:03 -0800 (PST) Received: from google.com ([2620:15c:183:200:d17d:9fe6:6a18:f270]) by smtp.gmail.com with ESMTPSA id h23sm1907101ila.81.2022.01.09.20.48.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Jan 2022 20:48:02 -0800 (PST) Date: Sun, 9 Jan 2022 21:47:57 -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-20220109_204804_639068_BE401CC4 X-CRM114-Status: GOOD ( 24.65 ) 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 03:44:50PM +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 > > + if (!mmap_read_trylock(mm)) > > + goto contended; > > Have you evaluated the behavior under mmap_sem contention? I mean what > would be an effect of some mms being excluded from the walk? This path > is called from direct reclaim and we do allocate with exclusive mmap_sem > IIRC and the trylock can fail in a presence of pending writer if I am > not mistaken so even the read lock holder (e.g. an allocation from the #PF) > can bypass the walk. You are right. Here it must be a trylock; otherwise it can deadlock. I think there might be a misunderstanding: the aging doesn't exclusively rely on page table walks to gather the accessed bit. It prefers page table walks but it can also fallback to the rmap-based function, i.e., lru_gen_look_around(), which only gathers the accessed bit from at most 64 PTEs and therefore is less efficient. But it still retains about 80% of the performance gains. > Or is this considered statistically insignificant thus a theoretical > problem? Yes. People who work on the maple tree and SPF at Google expressed the same concern during the design review meeting (all stakeholders on the mailing list were also invited). So we had a counter to monitor the contention in previous versions, i.e., MM_LOCK_CONTENTION in v4 here: https://lore.kernel.org/lkml/20210818063107.2696454-8-yuzhao@google.com/ And we also combined this patchset with the SPF patchset to see if the latter makes any difference. Our conclusion was the contention is statistically insignificant to the performance under memory pressure. This can be explained by how often we create a new generation. (We only walk page tables when we create a new generation. And it's similar to the low inactive condition for the active/inactive lru.) Usually we only do so every few seconds. We'd run into problems with other parts of the kernel, e.g., lru lock contention, i/o congestion, etc. if we create more than a few generation every second. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel