From: Yury Norov <yury.norov@gmail.com>
To: Alexander Potapenko <glider@google.com>
Cc: David Laight <David.Laight@aculab.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
pcc@google.com, Andrey Konovalov <andreyknvl@gmail.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
eugenis@google.com, Syed Nayyar Waris <syednwaris@gmail.com>,
william.gray@linaro.org
Subject: Re: [PATCH v5 2/5] lib/test_bitmap: add tests for bitmap_{read,write}()
Date: Sun, 1 Oct 2023 19:44:49 -0700 [thread overview]
Message-ID: <ZRoukg5eWDHICiei@yury-ThinkPad> (raw)
In-Reply-To: <CAG_fn=VYRdk0KV5tZaakjLLczdWTvGp2gfLjXqpYR2ifh4S4vA@mail.gmail.com>
On Fri, Sep 29, 2023 at 10:54:59AM +0200, Alexander Potapenko wrote:
> On Thu, Sep 28, 2023 at 10:02 PM Yury Norov <yury.norov@gmail.com> wrote:
> >
> > On Thu, Sep 28, 2023 at 05:14:55PM +0200, Alexander Potapenko wrote:
> > >
> > > So e.g. for compressing something into a 16-byte buffer using bitmaps
> > > I'd need to:
> > >
> > > 1) Allocate the buffer: buf = kmem_cache_alloc(...)
> > > 2) Allocate the bitmap: bitmap = bitmap_alloc(16*8, ...)
> > > 3) Fill the bitmap: mte_compress_to_buf(..., bitmap, 16)
> > > 4) Copy the bitmap contents to the buffer: bitmap_to_arr64(buf, bitmap, 16*8)
> > > 5) Deallocate the bitmap: bitmap_free(bitmap)
> > >
> > > instead of:
> > >
> > > buf = kmem_cache_alloc(...)
> > > mte_compress_to_buf(..., (unsigned long *)buf, 16)
> > >
> > > , correct?
> > >
> > > Given that the buffer contents are opaque and its size is aligned on 8
> > > bytes, could it be possible to somehow adopt the `buf` pointer
> > > instead?
> >
> > I didn't find an explicit typecasting where you're using
> > mte_compress_to_buf(), but now after hard 2nd look I see...
> >
> > Firstly, now that in the documentation you are explicitly describing the
> > return value of mte_compress() as 64-bit frame, the right way to go would
> > be declaring the function as: u64 mte_compress(u8 *tags).
>
> Ack.
>
> > And the general pattern should be like this:
> >
> > unsigned long mte_compress(u8 *tags)
> > {
> > DECLARE_BITMAP(tmp, MTECOMP_CACHES_MAXBITS);
> > void *storage;
> > ...
> > if (alloc_size < MTE_PAGE_TAG_STORAGE) {
> > storage = kmem_cache_alloc(cache, GFP_KERNEL);
> > mte_compress_to_buf(r_len, r_tags, r_sizes, tmp, alloc_size);
> >
> > switch (alloc_size) {
> > case 16:
> > bitmap_to_arr16(storage, tmp, 16);
>
> I might be missing something, but why do we need the switch at all?
> The buffers we are allocating always contain a whole number of u64's -
> cannot we just always call bitmap_to_arr64()?
>
> Note that for cases where alloc_size is > 8 we never make any
> assumptions about the contents of @storage, and don't care much about
> the byte order as long as swap decompression is done with the same
> endianness (which is always the case).
> (The case where alloc_size==8 is somewhat special, and needs more
> accurate handling, because we do make assumptions about the bit layout
> there).
So, this is my fault, and I'm really sorry. I read that 16-byte as
16-bit, and mistaken everything else. Please scratch the above.
If you allocate word-aligned memory, and it's a multiple of words,
which is your case, and access it only using bitmap API like
bitmap_read/write, everything should be fine.
Sorry again.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-10-02 2:45 UTC|newest]
Thread overview: 21+ 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 ` [PATCH v5 1/5] lib/bitmap: add bitmap_{read,write}() Alexander Potapenko
2023-09-22 8:08 ` [PATCH v5 2/5] lib/test_bitmap: add tests for bitmap_{read,write}() Alexander Potapenko
2023-09-25 12:16 ` Alexander Potapenko
2023-09-25 12:23 ` Andy Shevchenko
2023-09-25 13:09 ` Alexander Potapenko
2023-09-25 14:54 ` Alexander Potapenko
2023-09-25 16:06 ` Yury Norov
2023-09-25 17:16 ` Alexander Potapenko
2023-09-27 7:51 ` David Laight
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 19:59 ` Yury Norov
2023-09-29 8:54 ` Alexander Potapenko
2023-10-02 2:44 ` Yury Norov [this message]
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 ` [PATCH v5 4/5] arm64: mte: add a test for MTE tags compression Alexander Potapenko
2023-09-22 8:08 ` [PATCH v5 5/5] arm64: mte: add compression support to mteswap.c Alexander Potapenko
2023-09-22 14:35 ` [PATCH v5 0/5] Implement MTE tag compression for swapped pages Andy Shevchenko
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=ZRoukg5eWDHICiei@yury-ThinkPad \
--to=yury.norov@gmail.com \
--cc=David.Laight@aculab.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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).