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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 8EFC5C433E0 for ; Tue, 7 Jul 2020 03:43:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 52B07206E2 for ; Tue, 7 Jul 2020 03:43:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qnS1m895" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52B07206E2 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EF8856B000A; Mon, 6 Jul 2020 23:43:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAACD6B0010; Mon, 6 Jul 2020 23:43:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBDA66B0022; Mon, 6 Jul 2020 23:43:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id C607B6B000A for ; Mon, 6 Jul 2020 23:43:34 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8A9481EF1 for ; Tue, 7 Jul 2020 03:43:34 +0000 (UTC) X-FDA: 77009885148.12.foot99_530d12d26eb1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 61899180070D7 for ; Tue, 7 Jul 2020 03:43:34 +0000 (UTC) X-HE-Tag: foot99_530d12d26eb1 X-Filterd-Recvd-Size: 5924 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Jul 2020 03:43:33 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id 12so27298585oir.4 for ; Mon, 06 Jul 2020 20:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=c+m2RoLjPYbLg9a72QYT/s6oG2otjr54TDQZEh71EpE=; b=qnS1m895NYY2bNeQVaC1D4VXzrCXekz9bz+6vnIapPapUbel9BRC5VyY2y287eM05g GNH+TmkqcJb/nlczwypD+oXyh8PgBDZz9ABoZ+U0D7FnMb9RGgsYd1hYSLAwDMcC9qTo BEiJzVacUzS9mS8rnXaZmlNze8AUTsePLkdxhN9JnFpdBfDJ1jnVoharoZGcO00gciUw zeTqLVV07S8SiYOutN4ECrtzeBBSLCNbP0kwPa8mAiDRxgcoBAs+r9tNckQ1JtfpoMom GoGdstdomn8yyR44yneNGzfhjANV10Moh9+IzVNraoaxKIgW15k+eEmtqvrGBNfTs3vW tyfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=c+m2RoLjPYbLg9a72QYT/s6oG2otjr54TDQZEh71EpE=; b=Yei5gTJ0HEZHKoNTgXbBCEDpfcRJe/mDynNTLgk9g8js6P7j5gzAdjofaRhIBoeK67 hXhNtqMG0uw4uLPU4TmQY0UjhXP+42SJQ3obVzNq0yHYKKJ7305sllvDG72KyR5dF3JY dCQZJt4+ybMOM4pegLZbgGvC4K7nYUt+OeOhoR9rafv9RF7WgC18c35+gKqFcPxdMXv+ xN8224sVDbMgG/MrOtHHdtUulMkxm2dTWiCs3c4PUQcIwCMVa1DEJGDJO35NjeCD+O7T DbHPXnFdy8GaYV/ISkgWhJYd3+o1IQAsswKAahQx+9YAsgkRBZDfJohU+prVXM1rsLTa BRFw== X-Gm-Message-State: AOAM530YMl4SEzMjQDnLNPn/OHkCOMQbT28LPYC3alX56VokGBZbhFHu p0G9yF2YI1wka2gTQgr1D24GbA== X-Google-Smtp-Source: ABdhPJwRYTSEFY7Y46q8N3TkR9zuj81PcjEhB+2DZ4MNxmcML1V5raPiD+vzEnjydKBqs3kgorP6HQ== X-Received: by 2002:aca:ec16:: with SMTP id k22mr1869455oih.28.1594093413026; Mon, 06 Jul 2020 20:43:33 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id z14sm5712837ooz.17.2020.07.06.20.43.31 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Mon, 06 Jul 2020 20:43:32 -0700 (PDT) Date: Mon, 6 Jul 2020 20:43:30 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Matthew Wilcox cc: Hugh Dickins , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton Subject: Re: [PATCH 0/2] Use multi-index entries in the page cache In-Reply-To: <20200706185000.GC25523@casper.infradead.org> Message-ID: References: <20200629152033.16175-1-willy@infradead.org> <20200706144320.GB25523@casper.infradead.org> <20200706185000.GC25523@casper.infradead.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Queue-Id: 61899180070D7 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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: On Mon, 6 Jul 2020, Matthew Wilcox wrote: > > @@ -841,6 +842,7 @@ static int __add_to_page_cache_locked(struct page *page, > nr = thp_nr_pages(page); > } > > + VM_BUG_ON_PAGE(xa_load(&mapping->i_pages, offset + nr) == page, page); > page_ref_add(page, nr); > page->mapping = mapping; > page->index = offset; > @@ -880,6 +882,7 @@ static int __add_to_page_cache_locked(struct page *page, > goto error; > } > > + VM_BUG_ON_PAGE(xa_load(&mapping->i_pages, offset + nr) == page, page); > trace_mm_filemap_add_to_page_cache(page); > return 0; > error: > > The second one triggers with generic/051 (running against xfs with the > rest of my patches). So I deduce that we have a shadow entry which > takes up multiple indices, then when we store the page, we now have > a multi-index entry which refers to a single page. And this explains > basically all the accounting problems. I think you are jumping too far ahead by bringing in xfs and your later patches. Don't let me stop you from thinking ahead, but the problem at hand is with tmpfs. tmpfs doesn't use shadow entries, or not where we use the term "shadow" for workingset business: it does save swap entries as xarray values, but I don't suppose the five xfstests I was running get into swap (without applying additional pressure); and (since a huge page gets split before shmem swapout, at present anyway) I don't see a philosophical problem about their multi-index entries. Multi-index shadows, sorry, not a subject I can think about at present. > > Now I'm musing how best to fix this. > > 1. When removing a compound page from the cache, we could store only > a single entry. That seems bad because we cuold hit somewhere else in > the compound page and we'd have the wrong information about workingset > history (or worse believe that a shmem page isn't in swap!) > > 2. When removing a compound page from the cache, we could split the > entry and store the same entry N times. Again, this seems bad for shmem > because then all the swap entries would be the same, and we'd fetch the > wrong data from swap. > > 3 & 4. When adding a page to the cache, we delete any shadow entry which was > previously there, or replicate the shadow entry. Same drawbacks as the > above two, I feel. > > 5. Use the size of the shadow entry to allocate a page of the right size. > We don't currently have an API to find the right size, so that would > need to be written. And what do we do if we can't allocate a page of > sufficient size? > > So that's five ideas with their drawbacks as I see them. Maybe you have > a better idea? >