Re: [PATCH v17 44/47] dept: introduce APIs to set page usage and use subclasses_evt for the usage

On Wed, Nov 19, 2025 at 02:37:17PM +0000, Matthew Wilcox wrote:

On Wed, Nov 19, 2025 at 07:53:12PM +0900, Byungchul Park wrote:

quoted

On Thu, Oct 02, 2025 at 05:12:44PM +0900, Byungchul Park wrote:

quoted

False positive reports have been observed since dept works with the
assumption that all the pages have the same dept class, but the class
should be split since the problematic call paths are different depending
on what the page is used for.

At least, ones in block device's address_space and ones in regular
file's address_space have exclusively different usages.

Thus, define usage candidates like:

   DEPT_PAGE_REGFILE_CACHE /* page in regular file's address_space */
   DEPT_PAGE_BDEV_CACHE    /* page in block device's address_space */
   DEPT_PAGE_DEFAULT       /* the others */

1. I'd like to annotate a page to DEPT_PAGE_REGFILE_CACHE when the page
   starts to be associated with a page cache for fs data.

2. And I'd like to annotate a page to DEPT_PAGE_BDEV_CACHE when the page
   starts to be associated with meta data of fs e.g. super block.

3. Lastly, I'd like to reset the annotated value if any, that has been
   set in the page, when the page ends the assoication with either page
   cache or meta block of fs e.g. freeing the page.

Can anyone suggest good places in code for the annotation 1, 2, 3?  It'd
be totally appreciated. :-)

I don't think it makes sense to track lock state in the page (nor
folio).  Partly bcause there's just so many of them, but also because
the locking rules don't really apply to individual folios so much as
they do to the mappings (or anon_vmas) that contain folios.

Thank you for the suggestion!

Since two folios associated to different mappings might appear in the
same callpath that usually be classified to a single class, I need to
think how to reflect the suggestion.

I guess you wanted to tell me a folio can only be associated to a single
mapping at once.  Right?  If so, sure, I should reflect it.

If you're looking to find deadlock scenarios, I think it makes more
sense to track all folio locks in a given mapping as the same lock
type rather than track each folio's lock status.

For example, let's suppose we did something like this in the
page fault path:

Look up and lock a folio (we need folios locked to insert them into
the page tables to avoid a race with truncate)
Try to allocate a page table
Go into reclaim, attempt to reclaim a folio from this mapping

We ought to detect that as a potential deadlock, regardless of which
folio in the mapping we attempt to reclaim.  So can we track folio

Did you mean 'regardless' for 'potential' detection, right?

locking at the mapping/anon_vma level instead?

Piece of cake.  Even though it may increase the number of DEPT classes,
I hope it will be okay.  I just need to know the points in code where
folios start/end being associated to their specific mappings.

	Byungchul

---

My current understanding of folio locking rules:

If you hold a lock on folio A, you can take a lock on folio B if:

1. A->mapping == B->mapping and A->index < B->index
   (for example writeback; we take locks on all folios to be written
    back in order)
2. !S_ISBLK(A->mapping->host) and S_ISBLK(B->mapping->host)
3. S_ISREG(A->mapping->host) and S_ISREG(B->mapping->host) with
   inode_lock() held on both and A->index < B->index
   (the remap_range code)