Messages in this thread | | | From | Alexander Potapenko <> | Date | Fri, 22 Sep 2023 10:04:45 +0200 | Subject | Re: [PATCH v4 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP |
| |
> > +MTE assigns tags to memory pages: for 4K pages those tags occupy 128 bytes > > +(256 4-bit tags each corresponding to a 16-byte MTE granule). By default, MTE > > +carves out 3.125% (1/16) of the available physical memory to store the tags. > > + > > +When MTE pages are saved to swap, their tags need to be stored in the kernel > > +memory. If the system swap is used heavily, these tags may take a substantial > > +portion of the physical memory, which in the case of a zram-backed swap may > > +even exceed the memory used to store the swapped pages themselves. > > Hmm, I'm not sure about this claim ;). Is the zram so good that it > manages a 32x compression (4096/128)?
For trivial data, like zero pages, this is possible in theory, but I am not sure whether zram takes advantage of this. I removed the claim :)
> > How much would we save if we only do the compression when it can fit in > 63 bits?
Good question. What I've observed is that soon after boot roughly 50% of tag buffers can be compressed into 63 bits.
> > +void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes, > > + size_t *out_len) > > +{ ... > > +} > > +EXPORT_SYMBOL_NS(mte_tags_to_ranges, MTECOMP); > > What's with the exports here? Are we expecting these functions to be > called from loadable modules?
Yes, this is for the KUnit test module
> > -- > Catalin
-- Alexander Potapenko Software Engineer
Google Germany GmbH Erika-Mann-Straße, 33 80636 München
Geschäftsführer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
| |