From: Catalin Marinas <catalin.marinas@arm.com>
To: Alexander Potapenko <glider@google.com>
Cc: will@kernel.org, pcc@google.com, andreyknvl@gmail.com,
andriy.shevchenko@linux.intel.com, linux@rasmusvillemoes.dk,
yury.norov@gmail.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, eugenis@google.com,
syednwaris@gmail.com, william.gray@linaro.org
Subject: Re: [PATCH v4 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP
Date: Fri, 18 Aug 2023 18:57:13 +0100 [thread overview]
Message-ID: <ZN+w+RcanPRx5OVZ@arm.com> (raw)
In-Reply-To: <20230720173956.3674987-4-glider@google.com>
Just some random comments, I haven't reviewed the series properly.
On Thu, Jul 20, 2023 at 07:39:54PM +0200, Alexander Potapenko wrote:
> diff --git a/Documentation/arch/arm64/mte-tag-compression.rst b/Documentation/arch/arm64/mte-tag-compression.rst
> new file mode 100644
> index 0000000000000..af6716d53c1a8
> --- /dev/null
> +++ b/Documentation/arch/arm64/mte-tag-compression.rst
> @@ -0,0 +1,212 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==================================================
> +Tag Compression for Memory Tagging Extension (MTE)
> +==================================================
> +
> +This document describes the algorithm used to compress memory tags used by the
> +ARM Memory Tagging Extension (MTE)
> +
> +Introduction
> +============
> +
> +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)?
How much would we save if we only do the compression when it can fit in
63 bits?
> +/**
> + * mte_tags_to_ranges() - break @tags into arrays of tag ranges.
> + * @tags: 128-byte array containing 256 MTE tags.
> + * @out_tags: u8 array to store the tag of every range.
> + * @out_sizes: unsigned short array to store the size of every range.
> + * @out_len: length of @out_tags and @out_sizes (output parameter, initially
> + * equal to lengths of out_tags[] and out_sizes[]).
> + */
> +void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
> + size_t *out_len)
> +{
> + u8 prev_tag = tags[0] / 16; /* First tag in the array. */
> + unsigned int cur_idx = 0, i, j;
> + u8 cur_tag;
> +
> + memset(out_tags, 0, array_size(*out_len, sizeof(*out_tags)));
> + memset(out_sizes, 0, array_size(*out_len, sizeof(*out_sizes)));
> +
> + out_tags[0] = prev_tag;
> + for (i = 0; i < MTE_PAGE_TAG_STORAGE; i++) {
> + for (j = 0; j < 2; j++) {
> + cur_tag = j ? (tags[i] % 16) : (tags[i] / 16);
> + if (cur_tag == prev_tag) {
> + out_sizes[cur_idx]++;
> + } else {
> + cur_idx++;
> + prev_tag = cur_tag;
> + out_tags[cur_idx] = prev_tag;
> + out_sizes[cur_idx] = 1;
> + }
> + }
> + }
> + *out_len = cur_idx + 1;
> +}
> +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?
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Alexander Potapenko <glider@google.com>
Cc: will@kernel.org, pcc@google.com, andreyknvl@gmail.com,
andriy.shevchenko@linux.intel.com, linux@rasmusvillemoes.dk,
yury.norov@gmail.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, eugenis@google.com,
syednwaris@gmail.com, william.gray@linaro.org
Subject: Re: [PATCH v4 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP
Date: Fri, 18 Aug 2023 18:57:13 +0100 [thread overview]
Message-ID: <ZN+w+RcanPRx5OVZ@arm.com> (raw)
In-Reply-To: <20230720173956.3674987-4-glider@google.com>
Just some random comments, I haven't reviewed the series properly.
On Thu, Jul 20, 2023 at 07:39:54PM +0200, Alexander Potapenko wrote:
> diff --git a/Documentation/arch/arm64/mte-tag-compression.rst b/Documentation/arch/arm64/mte-tag-compression.rst
> new file mode 100644
> index 0000000000000..af6716d53c1a8
> --- /dev/null
> +++ b/Documentation/arch/arm64/mte-tag-compression.rst
> @@ -0,0 +1,212 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==================================================
> +Tag Compression for Memory Tagging Extension (MTE)
> +==================================================
> +
> +This document describes the algorithm used to compress memory tags used by the
> +ARM Memory Tagging Extension (MTE)
> +
> +Introduction
> +============
> +
> +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)?
How much would we save if we only do the compression when it can fit in
63 bits?
> +/**
> + * mte_tags_to_ranges() - break @tags into arrays of tag ranges.
> + * @tags: 128-byte array containing 256 MTE tags.
> + * @out_tags: u8 array to store the tag of every range.
> + * @out_sizes: unsigned short array to store the size of every range.
> + * @out_len: length of @out_tags and @out_sizes (output parameter, initially
> + * equal to lengths of out_tags[] and out_sizes[]).
> + */
> +void mte_tags_to_ranges(u8 *tags, u8 *out_tags, unsigned short *out_sizes,
> + size_t *out_len)
> +{
> + u8 prev_tag = tags[0] / 16; /* First tag in the array. */
> + unsigned int cur_idx = 0, i, j;
> + u8 cur_tag;
> +
> + memset(out_tags, 0, array_size(*out_len, sizeof(*out_tags)));
> + memset(out_sizes, 0, array_size(*out_len, sizeof(*out_sizes)));
> +
> + out_tags[0] = prev_tag;
> + for (i = 0; i < MTE_PAGE_TAG_STORAGE; i++) {
> + for (j = 0; j < 2; j++) {
> + cur_tag = j ? (tags[i] % 16) : (tags[i] / 16);
> + if (cur_tag == prev_tag) {
> + out_sizes[cur_idx]++;
> + } else {
> + cur_idx++;
> + prev_tag = cur_tag;
> + out_tags[cur_idx] = prev_tag;
> + out_sizes[cur_idx] = 1;
> + }
> + }
> + }
> + *out_len = cur_idx + 1;
> +}
> +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?
--
Catalin
next prev parent reply other threads:[~2023-08-18 17:57 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 17:39 [PATCH v4 0/5] Implement MTE tag compression for swapped pages Alexander Potapenko
2023-07-20 17:39 ` Alexander Potapenko
2023-07-20 17:39 ` [PATCH v4 1/5] lib/bitmap: add bitmap_{set,get}_value() Alexander Potapenko
2023-07-20 17:39 ` Alexander Potapenko
2023-07-23 1:57 ` Yury Norov
2023-07-23 1:57 ` Yury Norov
2023-07-23 15:38 ` Yury Norov
2023-09-22 7:48 ` Alexander Potapenko
2023-09-22 7:48 ` Alexander Potapenko
2023-07-24 8:36 ` Andy Shevchenko
2023-07-25 5:04 ` Yury Norov
2023-07-25 9:00 ` Andy Shevchenko
2023-07-26 8:08 ` Alexander Potapenko
2023-07-27 0:14 ` Yury Norov
2023-07-27 0:14 ` Yury Norov
2023-08-04 16:07 ` Alexander Potapenko
2023-08-04 16:07 ` Alexander Potapenko
2023-08-04 19:55 ` Yury Norov
2023-08-04 19:55 ` Yury Norov
2023-08-04 20:05 ` Andy Shevchenko
2023-08-04 20:05 ` Andy Shevchenko
2023-09-22 7:49 ` Alexander Potapenko
2023-09-22 7:49 ` Alexander Potapenko
2023-09-22 7:47 ` Alexander Potapenko
2023-09-22 7:47 ` Alexander Potapenko
2023-07-20 17:39 ` [PATCH v4 2/5] lib/test_bitmap: add tests for bitmap_{set,get}_value() Alexander Potapenko
2023-07-20 17:39 ` Alexander Potapenko
2023-07-23 2:29 ` Yury Norov
2023-07-23 2:29 ` Yury Norov
2023-09-22 7:57 ` Alexander Potapenko
2023-09-22 7:57 ` Alexander Potapenko
2023-09-22 13:28 ` Yury Norov
2023-09-22 13:28 ` Yury Norov
2023-09-27 12:33 ` Alexander Potapenko
2023-09-27 12:33 ` Alexander Potapenko
2023-07-20 17:39 ` [PATCH v4 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP Alexander Potapenko
2023-07-20 17:39 ` Alexander Potapenko
2023-07-21 11:22 ` Andy Shevchenko
2023-07-21 11:22 ` Andy Shevchenko
2023-09-22 8:03 ` Alexander Potapenko
2023-09-22 8:03 ` Alexander Potapenko
2023-08-18 17:57 ` Catalin Marinas [this message]
2023-08-18 17:57 ` Catalin Marinas
2023-09-22 8:04 ` Alexander Potapenko
2023-09-22 8:04 ` Alexander Potapenko
2023-07-20 17:39 ` [PATCH v4 4/5] arm64: mte: add a test for MTE tags compression Alexander Potapenko
2023-07-20 17:39 ` Alexander Potapenko
2023-07-21 11:25 ` Andy Shevchenko
2023-07-21 11:25 ` Andy Shevchenko
2023-09-22 8:05 ` Alexander Potapenko
2023-09-22 8:05 ` Alexander Potapenko
2023-07-20 17:39 ` [PATCH v4 5/5] arm64: mte: add compression support to mteswap.c Alexander Potapenko
2023-07-20 17:39 ` Alexander Potapenko
2023-08-18 18:18 ` Catalin Marinas
2023-08-18 18:18 ` Catalin Marinas
2023-09-20 13:26 ` Alexander Potapenko
2023-09-20 13:26 ` Alexander Potapenko
2023-09-20 16:18 ` Alexander Potapenko
2023-09-20 16:18 ` Alexander Potapenko
2023-09-20 14:22 ` Alexander Potapenko
2023-09-20 14:22 ` Alexander Potapenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZN+w+RcanPRx5OVZ@arm.com \
--to=catalin.marinas@arm.com \
--cc=andreyknvl@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=eugenis@google.com \
--cc=glider@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=pcc@google.com \
--cc=syednwaris@gmail.com \
--cc=will@kernel.org \
--cc=william.gray@linaro.org \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.