All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Alexander Potapenko <glider@google.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>, <pcc@google.com>,
	<andreyknvl@gmail.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 v5 0/5] Implement MTE tag compression for swapped pages
Date: Fri, 22 Sep 2023 16:40:26 +0200	[thread overview]
Message-ID: <8a4a6e1f-accb-92c2-ae14-9f6945e97f7a@intel.com> (raw)
In-Reply-To: <ZQ2mJ9rK7xNoMykL@smile.fi.intel.com>

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 22 Sep 2023 17:35:19 +0300

> +Cc: Olek, who internally is being developed something similar to your first
> patch here.

Oh, thanks.
The patch you mentioned properly implements cross-boundary accesses,
mine does not :D
But I guess we want to keep them both to keep the latter as optimized as
the current bitmap_{get,set}_value8()?

> 
> On Fri, Sep 22, 2023 at 10:08:42AM +0200, 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 in
>> this patch series is able to efficiently compress fixed-size tag buffers,
>> resulting in practical compression ratio between 2.5x and 4x. In most
>> cases it is possible to store the compressed data in 63-bit Xarray values,
>> resulting in no extra memory allocations.
>>
>> Our measurements show that the proposed algorithm provides better
>> compression than existing kernel compression algorithms (LZ4, LZO,
>> LZ4HC, ZSTD) can offer.

[...]

Thanks,
Olek

_______________________________________________
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: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Alexander Potapenko <glider@google.com>
Cc: <catalin.marinas@arm.com>, <will@kernel.org>, <pcc@google.com>,
	<andreyknvl@gmail.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 v5 0/5] Implement MTE tag compression for swapped pages
Date: Fri, 22 Sep 2023 16:40:26 +0200	[thread overview]
Message-ID: <8a4a6e1f-accb-92c2-ae14-9f6945e97f7a@intel.com> (raw)
In-Reply-To: <ZQ2mJ9rK7xNoMykL@smile.fi.intel.com>

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 22 Sep 2023 17:35:19 +0300

> +Cc: Olek, who internally is being developed something similar to your first
> patch here.

Oh, thanks.
The patch you mentioned properly implements cross-boundary accesses,
mine does not :D
But I guess we want to keep them both to keep the latter as optimized as
the current bitmap_{get,set}_value8()?

> 
> On Fri, Sep 22, 2023 at 10:08:42AM +0200, 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 in
>> this patch series is able to efficiently compress fixed-size tag buffers,
>> resulting in practical compression ratio between 2.5x and 4x. In most
>> cases it is possible to store the compressed data in 63-bit Xarray values,
>> resulting in no extra memory allocations.
>>
>> Our measurements show that the proposed algorithm provides better
>> compression than existing kernel compression algorithms (LZ4, LZO,
>> LZ4HC, ZSTD) can offer.

[...]

Thanks,
Olek

  reply	other threads:[~2023-09-22 14:42 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-22  8:08 [PATCH v5 0/5] Implement MTE tag compression for swapped pages Alexander Potapenko
2023-09-22  8:08 ` Alexander Potapenko
2023-09-22  8:08 ` [PATCH v5 1/5] lib/bitmap: add bitmap_{read,write}() Alexander Potapenko
2023-09-22  8:08   ` Alexander Potapenko
2023-09-22  8:08 ` [PATCH v5 2/5] lib/test_bitmap: add tests for bitmap_{read,write}() Alexander Potapenko
2023-09-22  8:08   ` Alexander Potapenko
2023-09-25 12:16   ` Alexander Potapenko
2023-09-25 12:16     ` Alexander Potapenko
2023-09-25 12:23     ` Andy Shevchenko
2023-09-25 12:23       ` Andy Shevchenko
2023-09-25 13:09       ` Alexander Potapenko
2023-09-25 13:09         ` Alexander Potapenko
2023-09-25 14:54         ` Alexander Potapenko
2023-09-25 14:54           ` Alexander Potapenko
2023-09-25 16:06           ` Yury Norov
2023-09-25 16:06             ` Yury Norov
2023-09-25 17:16             ` Alexander Potapenko
2023-09-25 17:16               ` Alexander Potapenko
2023-09-27  7:51           ` David Laight
2023-09-27  7:51             ` David Laight
2023-09-28 14:19             ` Alexander Potapenko
2023-09-28 14:19               ` Alexander Potapenko
     [not found]               ` <CAAH8bW-9ZWB=i0RWAWBXguOkguLHZGp7fLg7An73NqFnVmtgFw@mail.gmail.com>
2023-09-28 15:14                 ` Alexander Potapenko
2023-09-28 15:14                   ` Alexander Potapenko
2023-09-28 19:59                   ` Yury Norov
2023-09-28 19:59                     ` Yury Norov
2023-09-29  8:54                     ` Alexander Potapenko
2023-09-29  8:54                       ` Alexander Potapenko
2023-10-02  2:44                       ` Yury Norov
2023-10-02  2:44                         ` Yury Norov
2023-10-02  7:34                         ` Alexander Potapenko
2023-10-02  7:34                           ` Alexander Potapenko
2023-09-22  8:08 ` [PATCH v5 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP Alexander Potapenko
2023-09-22  8:08   ` Alexander Potapenko
2023-09-22  8:08 ` [PATCH v5 4/5] arm64: mte: add a test for MTE tags compression Alexander Potapenko
2023-09-22  8:08   ` Alexander Potapenko
2023-09-22  8:08 ` [PATCH v5 5/5] arm64: mte: add compression support to mteswap.c Alexander Potapenko
2023-09-22  8:08   ` Alexander Potapenko
2023-09-22 14:35 ` [PATCH v5 0/5] Implement MTE tag compression for swapped pages Andy Shevchenko
2023-09-22 14:35   ` Andy Shevchenko
2023-09-22 14:40   ` Alexander Lobakin [this message]
2023-09-22 14:40     ` Alexander Lobakin

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=8a4a6e1f-accb-92c2-ae14-9f6945e97f7a@intel.com \
    --to=aleksander.lobakin@intel.com \
    --cc=andreyknvl@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=catalin.marinas@arm.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.