Date:   Fri, 3 Mar 2023 07:03:36 +0000
From:   Matthew Wilcox <willy@infradead.org>
To:     Nhat Pham <nphamcs@gmail.com>
Cc:     akpm@linux-foundation.org, hannes@cmpxchg.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, bfoster@redhat.com, arnd@arndb.de,
        linux-api@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v10 2/3] cachestat: implement cachestat syscall
Message-ID: <ZAGbyM8xnLKC/2uX@casper.infradead.org>
References: <20230219073318.366189-1-nphamcs@gmail.com>
 <20230219073318.366189-3-nphamcs@gmail.com>
 <Y/IUTiL03C9OOSFx@casper.infradead.org>
 <CAKEwX=M7HSzSF6GZ_Nv26FQv_j+5UD9FQ_v3CL4=a1q5epyvPA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKEwX=M7HSzSF6GZ_Nv26FQv_j+5UD9FQ_v3CL4=a1q5epyvPA@mail.gmail.com>
Precedence: bulk

On Thu, Mar 02, 2023 at 10:55:48PM -0800, Nhat Pham wrote:
> On Sun, Feb 19, 2023 at 4:21 AM Matthew Wilcox <willy@infradead.org> wrote:
> > > +/**
> > > + * filemap_cachestat() - compute the page cache statistics of a mapping
> > > + * @mapping: The mapping to compute the statistics for.
> > > + * @first_index:     The starting page cache index.
> > > + * @last_index:      The final page index (inclusive).
> > > + * @cs:      the cachestat struct to write the result to.
> > > + *
> > > + * This will query the page cache statistics of a mapping in the
> > > + * page range of [first_index, last_index] (inclusive). The statistics
> > > + * queried include: number of dirty pages, number of pages marked for
> > > + * writeback, and the number of (recently) evicted pages.
> > > + */
> >
> > Do we care that this isn't going to work for hugetlbfs?
> 
> I ran a quick test using hugetlbfs. It looks like the current
> implementation is treating it in accordance to the multi-page
> folio case we discussed earlier, i.e:
> 
> - Returned number of "pages" is in terms of the number of
> base/small pages (i.e 512 dirty pages instead of 1 dirty
> huge page etc.)
> - If we touch one byte in the huge page, it would report the
> entire huge page as dirty, but again in terms of the underlying
> pages.
> 
> Is this what you have in mind, or is there another edge
> case that I'm missing...?

Hugetlbfs indexes its pages by hugepage number rather than by smallpage
number.  Imagine you have a 2MB folio at offset 4MB into the file.
Filesystems other than hugetlbfs store it at indices 1024-1535.
hugetlbfs stores it at index 2.

So your report probably seems to work, but if you ask it about a
range, you might be surprised by how wide that range will cover for
hugetlbfs.

I know Sidhartha is working on fixing that, but I'm not sure if what he
has is working yet.