LWN: Comments on "Repurposing page->mapping"

Repurposing page->mapping

willy — Fri, 27 Apr 2018 21:02:40 +0000

We actually have page_ext already ...

I'm not sure if anyone's considered putting per-page wait queues in there; I suspect not. The memory overhead might be deemed a little heavy.

Repurposing page->mapping

neilbrown — Fri, 27 Apr 2018 04:11:27 +0000

> Glisse concluded the session by acknowledging that most developers seemed to feel that this change "looks ugly".

Sounds like a perfect fit for 'struct page' then.

I actually think this is a good idea - have an 'extension' structure for pages to store details that are only used transiently or only on a tiny fraction of pages.
I would re-use private rather than mapping (sorry Chris) and the extension structure would contain:
- refcount
- private
- link back to the struct page
- anything else anyone wanted (flags,wait-queue-heads, linked list head...)
Any code that wanted to could add a page_extension at any time, and current users of private would need to be careful to get/update the right field. A couple of macros would make this easy.

This would have the added benefit that we would have to review all users of ->private, and we could use that opportunity to rename it to something grepable (pg_private) and change it from an unsigned long to a void star. That alone would make it all worth while.

Repurposing page->mapping

andresfreund — Fri, 27 Apr 2018 00:45:01 +0000

> The page structure is one of the most complex in the kernel due to the need to cram the maximum amount of information into as little space as possible. Each field is so heavily overloaded that developers prefer to avoid making changes to struct page if they can avoid it.

There was a session by Matthew Wilcox on Wednesday about cleaning that up, at least a bit. https://docs.google.com/spreadsheets/d/1tvCszs_7FXrjei9_m...