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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BF0CC433ED for ; Sat, 24 Apr 2021 03:30:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E49EB6146B for ; Sat, 24 Apr 2021 03:30:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E49EB6146B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 477716B0036; Fri, 23 Apr 2021 23:30:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 401386B006C; Fri, 23 Apr 2021 23:30:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22CCD6B006E; Fri, 23 Apr 2021 23:30:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F24656B0036 for ; Fri, 23 Apr 2021 23:30:44 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B05BE1801F76F for ; Sat, 24 Apr 2021 03:30:44 +0000 (UTC) X-FDA: 78065833608.39.B58AA80 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf08.hostedemail.com (Postfix) with ESMTP id A8F4180192F0 for ; Sat, 24 Apr 2021 03:30:20 +0000 (UTC) IronPort-SDR: VDmUXJggbnHIioFVNvq6xlynfaLH9QORniiERt4JezPf0FuNF0kIXtf05w8gWcfiEPh236rlmK yJbqDD9cxdaQ== X-IronPort-AV: E=McAfee;i="6200,9189,9963"; a="183288629" X-IronPort-AV: E=Sophos;i="5.82,247,1613462400"; d="scan'208";a="183288629" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2021 20:30:40 -0700 IronPort-SDR: GDpt/XE7DF3GrhacVF7Vpy23laFs/roeoUFy5BkMWagdXnUZPnMTIHXrOT2kg1nyQPmPbyfdlb ehwP5e+VqEkQ== X-IronPort-AV: E=Sophos;i="5.82,247,1613462400"; d="scan'208";a="535711869" Received: from tassilo.jf.intel.com ([10.54.74.11]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2021 20:30:40 -0700 Date: Fri, 23 Apr 2021 20:30:38 -0700 From: Andi Kleen To: Yu Zhao Cc: Michel Lespinasse , Rik van Riel , Ying Huang , Dave Chinner , Jens Axboe , SeongJae Park , Linux-MM , Andrew Morton , Benjamin Manes , Dave Hansen , Hillf Danton , Johannes Weiner , Jonathan Corbet , Joonsoo Kim , Matthew Wilcox , Mel Gorman , Miaohe Lin , Michael Larabel , Michal Hocko , Roman Gushchin , Rong Chen , SeongJae Park , Tim Chen , Vlastimil Babka , Yang Shi , Zi Yan , linux-kernel , lkp@lists.01.org, Kernel Page Reclaim v2 Subject: Re: [PATCH v2 00/16] Multigenerational LRU Framework Message-ID: <20210424033038.GP1401198@tassilo.jf.intel.com> References: <3ddd4f8a-8e51-662b-df11-a63a0e75b2bc@kernel.dk> <20210413231436.GF63242@dread.disaster.area> <20210414155130.GU3762101@tassilo.jf.intel.com> <20210415030002.GX3762101@tassilo.jf.intel.com> <20210415095708.GA6874@lespinasse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A8F4180192F0 X-Stat-Signature: oepc8t4sdhmko33hqeue3kwfayzbhy8b Received-SPF: none (linux.intel.com>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=mga02.intel.com; client-ip=134.134.136.20 X-HE-DKIM-Result: none/none X-HE-Tag: 1619235020-760456 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: > Now the question is how we build the bloom filter. A simple answer is > to let the rmap do the legwork, i.e., when it encounters dense > regions, add them to the filter. Of course this means we'll have to > use the rmap more than we do now, which is not ideal for some > workloads but necessary to avoid worst case scenarios. How would you maintain the bloom filter over time? Assume a process that always creates new mappings and unmaps old mappings. How do the stale old mappings get removed and avoid polluting it over time? Or are you thinking of one of the fancier bloom filter variants that support deletion? As I understand they're significantly less space efficient and more complicated. -Andi