Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34;
MIME-Version: 1.0
References: <20231113105234.32058-1-glider@google.com> <20231213123130.GC31326@willie-the-truck>
In-Reply-To: <20231213123130.GC31326@willie-the-truck>
From:   Alexander Potapenko <glider@google.com>
Date:   Wed, 13 Dec 2023 15:01:17 +0100
Message-ID: <CAG_fn=WsYJmcABW3aXDyGrd04Sh2Hi7_2rReLc5xXPjQ4paScQ@mail.gmail.com>
Subject: Re: [PATCH v9 0/4] Implement MTE tag compression for swapped pages
To:     Will Deacon <will@kernel.org>
Cc:     catalin.marinas@arm.com, pcc@google.com, andreyknvl@gmail.com,
        andriy.shevchenko@linux.intel.com, aleksander.lobakin@intel.com,
        linux@rasmusvillemoes.dk, yury.norov@gmail.com,
        alexandru.elisei@arm.com, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, eugenis@google.com,
        syednwaris@gmail.com, william.gray@linaro.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Dec 13, 2023 at 1:31=E2=80=AFPM Will Deacon <will@kernel.org> wrote=
:
>
> On Mon, Nov 13, 2023 at 11:52:29AM +0100, Alexander Potapenko wrote:
> > Currently, when MTE pages are swapped out, the tags are kept in the
> > memory, occupying PAGE_SIZE/32 bytes per page. This is especially
> > problematic for devices that use zram-backed in-memory swap, because
> > tags stored uncompressed in the heap effectively reduce the available
> > amount of swap memory.
> >
> > The RLE-based algorithm suggested by Evgenii Stepanov and implemented i=
n
> > this patch series is able to efficiently compress fixed-size tag buffer=
s,
> > resulting in practical compression ratio of 2x. In many cases it is
> > possible to store the compressed data in 63-bit Xarray values, resultin=
g
> > in no extra memory allocations.
> >
> > This patch series depends on "lib/bitmap: add bitmap_{read,write}()"
> > (https://lore.kernel.org/linux-arm-kernel/20231030153210.139512-1-glide=
r@google.com/T/)
> > that is mailed separately.
>
> That's a shame, because it means I can't apply the series as-is:
>

Uh-oh, sorry about that. There was another series depending on the
bitmap_read/bitmap_write API, and I thought mailing those patches
separately would speed things up.
But in fact Yury requested them to have at least one user, so now that
the MTE series is also acked I'd better bring everything back
together.
Let me send out another version.

>
> arch/arm64/mm/mtecomp.c: In function =E2=80=98mte_bitmap_write=E2=80=99:
> arch/arm64/mm/mtecomp.c:105:2: error: implicit declaration of function =
=E2=80=98bitmap_write=E2=80=99; did you mean =E2=80=98bitmap_free=E2=80=99?=
 [-Werror=3Dimplicit-function-declaration]
>   105 |  bitmap_write(bitmap, value, *pos, bits);
>       |  ^~~~~~~~~~~~
>       |  bitmap_free
> arch/arm64/mm/mtecomp.c: In function =E2=80=98mte_bitmap_read=E2=80=99:
> arch/arm64/mm/mtecomp.c:198:9: error: implicit declaration of function =
=E2=80=98bitmap_read=E2=80=99; did you mean =E2=80=98bitmap_remap=E2=80=99?=
 [-Werror=3Dimplicit-function-declaration]
>   198 |  return bitmap_read(bitmap, start, bits);
>       |         ^~~~~~~~~~~
>       |         bitmap_remap
> cc1: some warnings being treated as errors
> make[5]: *** [scripts/Makefile.build:243: arch/arm64/mm/mtecomp.o] Error =
1
>
>
> Do you really have such a hard dependency on those new bitmap ops?

Having them in bitmap.h seems natural - this way they can be reused by
other people.