Messages in this thread | | | From | Alexander Potapenko <> | Date | Mon, 2 Oct 2023 09:34:24 +0200 | Subject | Re: [PATCH v5 2/5] lib/test_bitmap: add tests for bitmap_{read,write}() |
| |
On Mon, Oct 2, 2023 at 4:44 AM Yury Norov <yury.norov@gmail.com> wrote: > > 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.
Ok, fine, I'll stick to the current implementation then.
| |