Messages in this thread | | | Date | Mon, 23 Oct 2023 19:22:23 +0200 | Subject | Re: [PATCH RFC 06/37] mm: page_alloc: Allocate from movable pcp lists only if ALLOC_FROM_METADATA | From | 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
| |