Messages in this thread | | | Date | Thu, 9 Nov 2023 16:38:41 +0000 | From | Matthew Wilcox <> | Subject | Re: [RFC][PATCH 1/4] mm, page_owner: add folio allocate post callback for struct page_owner to make the owner clearer |
| |
On Thu, Nov 09, 2023 at 04:04:39PM +0000, jeff.xie@linux.dev wrote: > November 9, 2023 at 11:36 PM, "Matthew Wilcox" <willy@infradead.org> wrote: > > But we want that anyway (or at least I do). You're right that vmalloc > > pages are not marked as being vmalloc pages and don't contain the > > information about which vmalloc area they belong to. I've talked about > > ways we can add that information to folios in the past, but I have a lot > > of other projects I'm working on. Are you interested in doing that? > > > > Certainly, I'm willing to give it a try. If a folio can include vmalloc information > or more information, this is great. I may need to understand the background of why > you proposed this method in the past.
I can't find the proposal now, but it's basically this:
Turn PG_slab into a PG_kernel. If PG_kernel is set, then other flags change their meaning. Flags that should be reusable: writeback, referenced, uptodate, lru, active, workingset, private, reclaim
One of those flags gets reused to be the new slab. So, eg folio_test_slab() becomes:
return (folio->flags & (PG_kernel | PG_slab)) == (PG_kernel | PG_slab);
Now we have somewhere that we can use for PG_vmalloc (also PG_reserved can become a PG_kernel sub-flag, freeing up a page flag).
We'd need to change some helpers. eg folio_mapping() currently does:
if (unlikely(folio_test_slab(folio))) return NULL;
and that should be:
if (unlikely(folio_test_kernel(folio))) return NULL;
With that in place, we can reuse the folio->mapping space to point to the struct vm_struct that allocated it.
This isn't an easy project and will require a lot of testing. It has some upsides, like freeing up a page flag.
| |