Re: [PATCH RFC 06/37] mm: page_alloc: Allocate from movable pcp lists only if ALLOC_FROM_METADATA

Hyesoo Yu
2023-10-23T07:27:35Z

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

On Tue, Oct 17, 2023 at 11:26:36AM +0100, Catalin Marinas wrote:
> On Mon, Oct 16, 2023 at 01:41:15PM +0100, Alexandru Elisei wrote:
> > On Thu, Oct 12, 2023 at 10:25:11AM +0900, Hyesoo Yu wrote:
> > > I don't think it would be effcient when the majority of movable pages
> > > do not use GFP_TAGGED.
> > >
> > > Metadata pages have a low probability of being in the pcp list
> > > because metadata pages is bypassed when freeing pages.
> > >
> > > The allocation performance of most movable pages is likely to decrease
> > > if only the request with ALLOC_FROM_METADATA could be allocated.
> >
> > You're right, I hadn't considered that.
> >
> > >
> > > How about not including metadata pages in the pcp list at all ?
> >
> > Sounds reasonable, I will keep it in mind for the next iteration of the
> > series.
>
> BTW, I suggest for the next iteration we drop MIGRATE_METADATA, only use
> CMA and assume that the tag storage itself supports tagging. Hopefully
> it makes the patches a bit simpler.
>

I am curious about the plan for the next iteration.

Does tag storage itself supports tagging? Will the following version be unusable
if the hardware does not support it? The document of google said that
"If this memory is itself mapped as Tagged Normal (which should not happen!)
then tag updates on it either raise a fault or do nothing, but never change the
contents of any other page."
(https://github.com/google/sanitizers/blob/master/mte-dynamic-carveout/spec.md)

The support of H/W is very welcome because it is good to make the patches simpler.
But if H/W doesn't support it, Can't the new solution be used?

Thanks,
Regards.

> --
> Catalin
>

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]