linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pankaj Raghav <kernel@pankajraghav.com>
To: minchan@kernel.org, senozhatsky@chromium.org
Cc: linux-kernel@vger.kernel.org, axboe@kernel.dk,
	p.raghav@samsung.com, linux-block@vger.kernel.org,
	kernel@pankajraghav.com, gost.dev@samsung.com
Subject: [PATCH 3/5] zram: add alloc_block_bdev_range() and free_block_bdev_range()
Date: Mon, 11 Sep 2023 15:34:28 +0200	[thread overview]
Message-ID: <20230911133430.1824564-4-kernel@pankajraghav.com> (raw)
In-Reply-To: <20230911133430.1824564-1-kernel@pankajraghav.com>

From: Pankaj Raghav <p.raghav@samsung.com>

Add [alloc|free]_block_bdev_range() which accepts number of blocks to
allocate or free from the block bitmap.

alloc_block_bdev_range() tries to allocate a range of bitmap based in
the input nr_of_blocks whenever possible, or else it will retry with a
smaller value. This is done so that we don't unnecessarily return EIO
when the underlying device is fragmented.

alloc_block_bdev_range() is not an atomic operation as this function can
be called only from writeback_store() and init_lock is anyway taken
making sure there cannot be two processes allocating from bdev bitmap.

free_block_bdev_range() is just a simple loop that calls the atomic
free_block_bdev() function. As bdev bitmap free can be called from
two different process simulataneously without a lock, atomicity needs
to be maintained.

This is useful when we want to send larger IOs to the backing dev.

Signed-off-by: Pankaj Raghav <p.raghav@samsung.com>
---
 drivers/block/zram/zram_drv.c | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index bd93ed653b99..0b8f814e11dd 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -576,6 +576,39 @@ static void free_block_bdev(struct zram *zram, unsigned long blk_idx)
 	atomic64_dec(&zram->stats.bd_count);
 }
 
+static unsigned long alloc_block_bdev_range(struct zram *zram,
+					    unsigned int *nr_of_blocksp)
+{
+	unsigned long blk_idx;
+	unsigned int nr_of_blocks = *nr_of_blocksp;
+retry:
+	/* skip 0 bit to confuse zram.handle = 0 */
+	blk_idx = 1;
+	blk_idx = bitmap_find_next_zero_area(zram->bitmap, zram->nr_pages,
+					     blk_idx, nr_of_blocks, 0);
+
+	if ((blk_idx + nr_of_blocks) > zram->nr_pages) {
+		if (nr_of_blocks == 1)
+			return 0;
+
+		nr_of_blocks = nr_of_blocks / 2;
+		goto retry;
+	}
+
+	bitmap_set(zram->bitmap, blk_idx, nr_of_blocks);
+	atomic64_add(nr_of_blocks, &zram->stats.bd_count);
+	*nr_of_blocksp = nr_of_blocks;
+
+	return blk_idx;
+}
+
+static void free_block_bdev_range(struct zram *zram, unsigned long blk_idx,
+				  unsigned int nr_of_blocks)
+{
+	for (unsigned int i = 0; i < nr_of_blocks; i++)
+		free_block_bdev(zram, blk_idx + i);
+}
+
 static void read_from_bdev_async(struct zram *zram, struct page *page,
 			unsigned long entry, struct bio *parent)
 {
-- 
2.40.1


  parent reply	other threads:[~2023-09-11 21:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20230911133442eucas1p2f773a475e0a6dc1a448c63884d58c8d3@eucas1p2.samsung.com>
2023-09-11 13:34 ` [PATCH 0/5] Improve zram writeback performance Pankaj Raghav
2023-09-11 13:34   ` [PATCH 1/5] zram: move index preparation to a separate function in writeback_store Pankaj Raghav
2023-09-11 13:34   ` [PATCH 2/5] zram: encapsulate writeback to the backing bdev in a function Pankaj Raghav
2023-09-11 13:34   ` Pankaj Raghav [this message]
2023-09-11 13:34   ` [PATCH 4/5] zram: batch IOs during writeback to improve performance Pankaj Raghav
2023-09-11 13:34   ` [PATCH 5/5] zram: don't overload blk_idx variable in writeback_store() Pankaj Raghav
2023-09-18 13:53   ` [PATCH 0/5] Improve zram writeback performance Pankaj Raghav
2023-09-19  0:33     ` Sergey Senozhatsky
2023-09-19 14:20       ` Pankaj Raghav
2024-09-25 15:53       ` Jassi Brar
2024-09-26  4:33         ` Sergey Senozhatsky
2024-09-29 22:21           ` Jassi Brar
2024-09-26  4:41   ` Sergey Senozhatsky

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=20230911133430.1824564-4-kernel@pankajraghav.com \
    --to=kernel@pankajraghav.com \
    --cc=axboe@kernel.dk \
    --cc=gost.dev@samsung.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=p.raghav@samsung.com \
    --cc=senozhatsky@chromium.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).