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

[David Hildenbrand]

On 23.10.23 19:08, Catalin Marinas wrote:
> On Mon, Oct 23, 2023 at 01:55:12PM +0200, David Hildenbrand wrote:
> > On 23.10.23 12:50, Catalin Marinas wrote:
> > > On Mon, Oct 23, 2023 at 04:16:56PM +0900, Hyesoo Yu wrote:
> > > > 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?
> > >
> > > AFAIK on the current interconnects this is supported but the offsets
> > > will need to be configured by firmware in such a way that a tag access
> > > to the tag carve-out range still points to physical RAM, otherwise, as
> > > per Google's doc, you can get some unexpected behaviour.
> [...]
> > I followed what you are saying, but I didn't quite read the following
> > clearly stated in your calculations: Using this model, how much memory would
> > you be able to reuse, and how much not?
> >
> > I suspect you would *not* be able to reuse "1/(32*32)" [second carve-out]
> > but be able to reuse "1/32 - 1/(32*32)" [first carve-out] or am I completely
> > off?
>
> That's correct. In theory, from the hardware perspective, we could even
> go recursively to the third/fourth etc. carveout until the last one is a
> single page but I'd rather not complicate things further.
>
> > Further, (just thinking about it) I assume you've taken care of the
> > condition that memory cannot self-host it's own tag memory. So that cannot
> > happen in the model proposed here, right?
>
> I don't fully understand what you mean. The tags for the first data
> range (0 .. ram_size * 31/32) are stored in the first tag carveout.
> That's where we'll need CMA. For the tag carveout, when hosting data
> pages as tagged, the tags go in the second carveout which is fully
> reserved (still TBD but possibly the firmware won't even tell the kernel
> about it).

You got my cryptic question right: you make sure that the tag for the 
first carveout go to the second carveout.

Sounds very good, thanks.

--
Cheers,

David / dhildenb