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 047BAC433F5 for ; Thu, 7 Apr 2022 03:05:59 +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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IlhB8A3oiDLO629VbKuPrzj98z07ogFQIfRws+Xuws8=; b=h0/uUSR6jjaOMM hu21xS3+EndrRVO39hGCz4zfYcAnXoKoIhXTGP6tbZ0ZBSbl26bz5CFWwXAEBUOJ1kux23VxJNpim GPKwTtYO9qzRQRhifH7Qd8c6BC+E1Dy9kyhvjbUb0T1ZrW4LYURVaJQi0YWCbAaef5Qp9vQ477j4e E903Zx01asGKBn7+q1WOzN8HoEeLzSrnvMIrDIs1SyEoKrZ4x9EfWIuImene7P+ZKbMbz7pOKfNL+ /8fHTxzGJi7lHgPLsjuOfeK0LtKgQVmil5xGptDOJdTPaaVUacc9cdeKSWk86rZwT5OOmoDNqlw8a AlCn68KFSBGTMuB0JlBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncIS5-008xQU-2R; Thu, 07 Apr 2022 03:04:53 +0000 Received: from mail-vs1-xe31.google.com ([2607:f8b0:4864:20::e31]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ncIRv-008xLC-Sg for linux-arm-kernel@lists.infradead.org; Thu, 07 Apr 2022 03:04:45 +0000 Received: by mail-vs1-xe31.google.com with SMTP id r1so2398254vsi.12 for ; Wed, 06 Apr 2022 20:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JlG6HVFbiriXMTJdqZSQqniMpGFV8xnAyrnEzIlMNOY=; b=g3dD8HMIW9o4XOj5/F4RYCZnbEq63R4EFyiRBbXsQlUUpD8109X/uRO1gnNIi0+9Pi lM1gQs/hacv3X7DHc77AbOsPgGGj22DYZPNeVsSVPpo97gzaVorDV1FW/tOTqx+DYT/P jBJwysHsCHMQOUC3rMpl0RAjgDGuNdLmjaqRyAgu6yjOnfQwLgp70zPEKn1m4byVx+Gn oaQ4TwpPmIJlhF6DGjFJDaCj+IZModFF71wQbWOneko1mH8M9Gnp2X+nPDvv8I+bcUjq 1KXKi2GF347JNly/H9fpusZvX9svfQ6yBM2A9CFZJRzmHwYsiNuDABJBRzlGNgaeCuWI BRNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JlG6HVFbiriXMTJdqZSQqniMpGFV8xnAyrnEzIlMNOY=; b=aEr6TvA0G74qwB4zmGZ8RcurliKo0PPUsUYkmwC7/Af1KXrFZmyQa/51W//ZA4k4Jl 9vJuARCAnXaLYtgQ3yCrQcfweOS/Ikjj5hbz2zaDAjHZs+xDgbKnw7rFa19Lp+1xdprc DdEMTvAYoqEiaD3Z6/W4ouJRwrHcxwGdulHXNLleGPNNUxorCcyMgm1J0Av175tNuN7e IEHbkKbwKGaok8LuP9BVvSyhyavIPUZBR0FQxJ0moCYDaleSjl2Bxc2OCEzzVjFJ1NBj YcN34/mfN3GGDDkCA339EJDaVixc1Zb2+1I+qZIG9jwaWGfjMXOgg9TXeOwkRhfxKl5k H7vw== X-Gm-Message-State: AOAM531NjC2mF3ZvnMSHfI6vT8qZp6wI4YdCDcaChT62mvu9I690hV7M IgE1tBcn38CAqcDYh3AVJwGDDKlJ+qF6nKxIjoV41g== X-Google-Smtp-Source: ABdhPJyuYJMGr6LXPgy65MMvs9O/WDf8CYTQgrUNNgYQ5HIVVErldv2mOXJVQnNH++zy/vxigLt2YykfDAtVJj3qS2Q= X-Received: by 2002:a05:6102:2922:b0:325:7818:8669 with SMTP id cz34-20020a056102292200b0032578188669mr4104348vsb.41.1649300678575; Wed, 06 Apr 2022 20:04:38 -0700 (PDT) MIME-Version: 1.0 References: <20220309021230.721028-1-yuzhao@google.com> <20220309021230.721028-8-yuzhao@google.com> In-Reply-To: From: Yu Zhao Date: Wed, 6 Apr 2022 21:04:27 -0600 Message-ID: Subject: Re: [PATCH v9 07/14] mm: multi-gen LRU: exploit locality in rmap To: Barry Song <21cnbao@gmail.com> Cc: Andrew Morton , Linus Torvalds , Andi Kleen , Aneesh Kumar , Catalin Marinas , Dave Hansen , Hillf Danton , Jens Axboe , Jesse Barnes , Johannes Weiner , Jonathan Corbet , Matthew Wilcox , Mel Gorman , Michael Larabel , Michal Hocko , Mike Rapoport , Rik van Riel , Vlastimil Babka , Will Deacon , Ying Huang , LAK , Linux Doc Mailing List , LKML , Linux-MM , Kernel Page Reclaim v2 , x86 , Brian Geffon , Jan Alexander Steffens , Oleksandr Natalenko , Steven Barrett , Suleiman Souhlal , Daniel Byrne , Donald Carr , =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Konstantin Kharlamov , Shuang Zhai , Sofia Trinh , Vaibhav Jain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220406_200444_034980_2BF17D9F X-CRM114-Status: GOOD ( 25.66 ) 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 Wed, Apr 6, 2022 at 8:29 PM Barry Song <21cnbao@gmail.com> wrote: > > On Wed, Mar 9, 2022 at 3:48 PM Yu Zhao wrote: > > > > Searching the rmap for PTEs mapping each page on an LRU list (to test > > and clear the accessed bit) can be expensive because pages from > > different VMAs (PA space) are not cache friendly to the rmap (VA > > space). For workloads mostly using mapped pages, the rmap has a high > > CPU cost in the reclaim path. > > > > This patch exploits spatial locality to reduce the trips into the > > rmap. When shrink_page_list() walks the rmap and finds a young PTE, a > > new function lru_gen_look_around() scans at most BITS_PER_LONG-1 > > adjacent PTEs. On finding another young PTE, it clears the accessed > > bit and updates the gen counter of the page mapped by this PTE to > > (max_seq%MAX_NR_GENS)+1. > > Hi Yu, > It seems an interesting feature to save the cost of rmap. but will it lead to > possible judging of cold pages as hot pages? > In case a page is mapped by 20 processes, and it has been accessed > by 5 of them, when we look around one of the 5 processes, the page > will be young and this pte is cleared. but we still have 4 ptes which are not > cleared. then we don't access the page for a long time, but the 4 uncleared > PTEs will still make the page "hot" since they are not cleared, we will find > the page is hot either due to look-arounding the 4 processes or rmapping > the page later? Why are the remaining 4 accessed PTEs skipped? The rmap should check all the 20 PTEs. Even if they were skipped, it doesn't matter. The same argument could be made for the rest of 1 millions minus 1 pages that have been timely scanned, on a 4GB laptop. The fundamental principle (assumption) of MGLRU is never about making the best choices. Nothing can because it's impossible to predict the future that well, given the complexity of today's workloads, not on a phone, definitely not on a server that runs mixed types of workloads. The primary goal is to avoid the worst choices at a minimum (scanning) cost. The second goal is to pick good ones at an acceptable cost, which probably are a half of all possible choices. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel