mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Chaitanya Kulkarni <kch@nvidia.com>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: axboe@kernel.dk, johannes.thumshirn@wdc.com, bvanassche@acm.org,
	ming.lei@redhat.com, shinichiro.kawasaki@wdc.com,
	vincent.fu@samsung.com, yukuai3@huawei.com
Subject: Re: [PATCH 2/6] null_blk: allow write zeores on membacked
Date: Wed, 5 Oct 2022 13:57:39 +0900	[thread overview]
Message-ID: <89b93617-2fb1-3757-9f80-ddc06f02683f@opensource.wdc.com> (raw)
In-Reply-To: <20221005031701.79077-3-kch@nvidia.com>

On 10/5/22 12:16, Chaitanya Kulkarni wrote:
> Add a helper functions to enable the REQ_OP_WRITE_ZEROES operations
> when null_blk is configured with the membacked mode.
> 
> Since write-zeroes is a non-trivial I/O operation we need this to
> add a blktest so we can test the non-trivial I/O path from the
> application to the block layer.

Why a separate patch for this ? Introducing the module argument and
configfs equivalent separately in 2 different patches is strange and does
not facilitate review.

This patch should be merged with patch 1.

> 
> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
> ---
>  drivers/block/null_blk/main.c | 46 ++++++++++++++++++++++++++++++++++-
>  1 file changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c
> index fc3e883f7b84..2d592b4eb815 100644
> --- a/drivers/block/null_blk/main.c
> +++ b/drivers/block/null_blk/main.c
> @@ -420,6 +420,7 @@ NULLB_DEVICE_ATTR(blocking, bool, NULL);
>  NULLB_DEVICE_ATTR(use_per_node_hctx, bool, NULL);
>  NULLB_DEVICE_ATTR(memory_backed, bool, NULL);
>  NULLB_DEVICE_ATTR(discard, bool, NULL);
> +NULLB_DEVICE_ATTR(write_zeroes, bool, NULL);
>  NULLB_DEVICE_ATTR(mbps, uint, NULL);
>  NULLB_DEVICE_ATTR(cache_size, ulong, NULL);
>  NULLB_DEVICE_ATTR(zoned, bool, NULL);
> @@ -544,6 +545,7 @@ static struct configfs_attribute *nullb_device_attrs[] = {
>  	&nullb_device_attr_power,
>  	&nullb_device_attr_memory_backed,
>  	&nullb_device_attr_discard,
> +	&nullb_device_attr_write_zeroes,
>  	&nullb_device_attr_mbps,
>  	&nullb_device_attr_cache_size,
>  	&nullb_device_attr_badblocks,
> @@ -618,7 +620,7 @@ static ssize_t memb_group_features_show(struct config_item *item, char *page)
>  			"poll_queues,power,queue_mode,shared_tag_bitmap,size,"
>  			"submit_queues,use_per_node_hctx,virt_boundary,zoned,"
>  			"zone_capacity,zone_max_active,zone_max_open,"
> -			"zone_nr_conv,zone_size\n");
> +			"zone_nr_conv,zone_size,write_zeroes\n");
>  }
>  
>  CONFIGFS_ATTR_RO(memb_group_, features);
> @@ -875,6 +877,24 @@ static void null_free_sector(struct nullb *nullb, sector_t sector,
>  	}
>  }
>  
> +static void null_zero_sector(struct nullb_device *d, sector_t sect,
> +			     sector_t nr_sects, bool cache)
> +{
> +	struct radix_tree_root *root = cache ? &d->cache : &d->data;
> +	struct nullb_page *t_page;
> +	unsigned int offset;
> +	void *dest;
> +
> +	t_page = radix_tree_lookup(root, sect >> PAGE_SECTORS_SHIFT);
> +	if (!t_page)
> +		return;
> +
> +	offset = (sect & SECTOR_MASK) << SECTOR_SHIFT;
> +	dest = kmap_atomic(t_page->page);
> +	memset(dest + offset, 0, SECTOR_SIZE * nr_sects);
> +	kunmap_atomic(dest);
> +}
> +
>  static struct nullb_page *null_radix_tree_insert(struct nullb *nullb, u64 idx,
>  	struct nullb_page *t_page, bool is_cache)
>  {
> @@ -1191,6 +1211,27 @@ blk_status_t null_handle_discard(struct nullb_device *dev,
>  	return BLK_STS_OK;
>  }
>  
> +static blk_status_t null_handle_write_zeroes(struct nullb_device *dev,
> +					     sector_t sector, sector_t nr_sectors)
> +{
> +	unsigned int bytes_left = nr_sectors << 9;
> +	struct nullb *nullb = dev->nullb;
> +	size_t curr_bytes;
> +
> +	spin_lock_irq(&nullb->lock);
> +	while (bytes_left > 0) {
> +		curr_bytes = min_t(size_t, bytes_left, nullb->dev->blocksize);
> +		nr_sectors = curr_bytes >> SECTOR_SHIFT;
> +		null_zero_sector(nullb->dev, sector, nr_sectors, false);
> +		if (null_cache_active(nullb))
> +			null_zero_sector(nullb->dev, sector, nr_sectors, true);
> +		sector += nr_sectors;
> +		bytes_left -= curr_bytes;
> +	}
> +	spin_unlock_irq(&nullb->lock);
> +	return BLK_STS_OK;
> +}
> +
>  static int null_handle_flush(struct nullb *nullb)
>  {
>  	int err;
> @@ -1357,6 +1398,9 @@ static inline blk_status_t null_handle_memory_backed(struct nullb_cmd *cmd,
>  	if (op == REQ_OP_DISCARD)
>  		return null_handle_discard(dev, sector, nr_sectors);
>  
> +	if (op == REQ_OP_WRITE_ZEROES)
> +		return null_handle_write_zeroes(dev, sector, nr_sectors);
> +
>  	if (dev->queue_mode == NULL_Q_BIO)
>  		err = null_handle_bio(cmd);
>  	else

-- 
Damien Le Moal
Western Digital Research


  reply	other threads:[~2022-10-05  4:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05  3:16 [PATCH 0/6] null_blk: allow REQ_OP_WRITE_ZEROES and cleanup Chaitanya Kulkarni
2022-10-05  3:16 ` [PATCH 1/6] null_blk: allow write zeores on non-membacked Chaitanya Kulkarni
2022-10-05  4:54   ` Damien Le Moal
2022-10-05  5:24     ` Chaitanya Kulkarni
2022-10-05 18:33       ` Chaitanya Kulkarni
2022-10-05  3:16 ` [PATCH 2/6] null_blk: allow write zeores on membacked Chaitanya Kulkarni
2022-10-05  4:57   ` Damien Le Moal [this message]
2022-10-05  5:10     ` Chaitanya Kulkarni
2022-10-05 17:18   ` Brian Foster
2022-10-05  3:16 ` [PATCH 3/6] null_blk: code cleaup Chaitanya Kulkarni
2022-10-05  5:02   ` Damien Le Moal
2022-10-05  5:21     ` Chaitanya Kulkarni
2022-10-05  3:16 ` [PATCH 4/6] null_blk: initialize cmd->bio in __alloc_cmd() Chaitanya Kulkarni
2022-10-05  5:04   ` Damien Le Moal
2022-10-05  3:17 ` [PATCH 5/6] null_blk: don't use magic numbers in the code Chaitanya Kulkarni
2022-10-05  5:05   ` Damien Le Moal
2022-10-05  3:17 ` [PATCH 6/6] null_blk: remove extra space in switch condition Chaitanya Kulkarni
2022-10-05  5:06   ` Damien Le Moal

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=89b93617-2fb1-3757-9f80-ddc06f02683f@opensource.wdc.com \
    --to=damien.lemoal@opensource.wdc.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=johannes.thumshirn@wdc.com \
    --cc=kch@nvidia.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=vincent.fu@samsung.com \
    --cc=yukuai3@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®