Re: PageOffline: refcount, flags and memdesc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 14, 2024 at 04:55:33PM +0100, David Hildenbrand wrote:
> > Thanks for bringing it up.  As a memdesc, I currently have PageOffline
> > as being type 0 (Misc), subtype 5 (Offline).  That's bits 0-10 and then
> > bit 11 is for "may be mapped to userspace".  Bits 12-17 are the order.
> > With the top bits being used for section/node/zone, that could be 25 +
> > 12 + 3 = 40 bits, so we'd have 7 bits remaining for use as flags.
> 
> "may be mapped to userspace" will always be 0. 1 / 2 flags initially would
> do.

Yes, indeed, would always be 0 for Offline pages.  Probably not for
other pages though, and I'd like to have that property as a standard
flag.

> > > free_offline_page()
> > > free_offline_page_range()
> > > 
> > > And
> > > 
> > > alloc_offline_page()
> > > alloc_offline_page_range()
> > > alloc_offline_pages
> > > 
> > > I'm not super happy about the "alloc/free" terminology, but nothing better
> > > came to mind.
> > 
> > If I resurrect
> > https://lore.kernel.org/linux-mm/20220809171854.3725722-1-willy@xxxxxxxxxxxxx/
> > would the frozen terminology work for you here?
> 
> Ah, I remember that.
> 
> I was more concerned about alloc/free terminology, because
> "free_offline_page" could simply be "online_page" :) But the "allocation"
> part is trickier. Maybe it's simply alloc/free of frozen pages for the time
> being.
> 
> But yes, the "allocate/free pages without involving refcounts" will be a
> crucial thing to get the PageOffline conversion flying.
> 
> Instead of alloc_frozen_pages(), I was wondering if we should have something
> like GFP_FROZEN. For example, for two PG_offline users
> I'd currently also need alloc_contig_frozen_range() and
> alloc_contig_frozen_pages(). Using alloc_contig_range(GFP_FROZEN)
> alloc_contig_pages(GFP_PROZEN) would make that easier.
> 
> Did you consider that already?

I think Yu Zhao's recent patches:

e98337d11bbd ("mm/contig_alloc: support __GFP_COMP")
463586e9ff39 ("mm/cma: add cma_{alloc,free}_folio()")
cf54f310d0d3 ("mm/hugetlb: use __GFP_COMP for gigantic folios")

get us most of the way there.

What I really want to do is make contig allocation not do anything with
the refcounts.  Hoist that into the callers which actually want it
(probably not many), and then we can actually drop the __GFP_COMP
support to alloc_contig_range_noprof().





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux