Re: [PATCH v4 5/5] arm64: mte: add compression support to mteswap.c
From: Alexander Potapenko <glider@google.com>
Date: 2023-09-20 16:19:40
Also in:
lkml
On Wed, Sep 20, 2023 at 3:26 PM Alexander Potapenko [off-list ref] wrote:
On Fri, Aug 18, 2023 at 8:18 PM Catalin Marinas [off-list ref] wrote:quoted
On Thu, Jul 20, 2023 at 07:39:56PM +0200, Alexander Potapenko wrote:quoted
Soon after booting Android, tag compression saves ~2.5x memory previously spent by mteswap.c on tag allocations. With the growing uptime, the savings reach 20x and even more.This sounds like a marketing claim ;). The way I read your statement is that the memory used for tag storage is 2.5x less with your patches and that's great. It means a 2.5x compression on average. How does the compression get so much better to 20x with more uptime?I am currently looking at this, and I think this happens because some userspace apps assign zero tags to userspace pages, and those tags are effectively zero-cost, because they can be compressed into 8 bytes of the Xarray pointer. As the uptime grows, the share of such pages also grows. I agree though that this is a marginal use case, and the average compression rate is more representative.quoted
The number of tag storage allocations should be proportional to the pages swapped out (not equal as not all would be mapped as PROT_MTE).We think a reasonable upper bound for PROT_MTE pages is 40%, but currently it is probably more like 20%.quoted
So you can indeed have a lot more pages swapped out than available in RAM and the tag storage can take space but not sure which numbers you divided to get 20x.Right now (in kernel 6.5) the amount of memory spent to store the tags can be calculated as 128 * (number of mte_allocate_tag_storage() calls - number of mte_free_tag_storage() calls). In my patchset I calculate the total amount of memory allocated/deallocated from the mte-tags-N caches and compare that with 128 * (total number of live objects in those caches). E.g. the stats after booting up the device (~120s uptime) look as follows: 8 bytes: 14007 allocations, 256 deallocations 16 bytes: 1583 allocations, 179 deallocations 32 bytes: 1634 allocations, 205 deallocations 64 bytes: 1538 allocations, 142 deallocations 128 bytes: 10881 allocations, 1340 deallocations uncompressed tag storage size: 3522688 compressed tag storage size: 1488792 (note 8-byte allocations contribute to uncompressed storage, but not to compressed storage). After running various apps, I made the device use almost 19Mb swap space:
Sorry, this is by no means 19Mb
8 bytes: 71352 allocations, 8093 deallocations 16 bytes: 5102 allocations, 2598 deallocations 32 bytes: 8206 allocations, 4536 deallocations 64 bytes: 9489 allocations, 5377 deallocations 128 bytes: 43258 allocations, 23364 deallocations uncompressed tag storage size: 11960192 compressed tag storage size: 2967104
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel