From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Max Gurtovoy <mgurtovoy@nvidia.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"axboe@kernel.dk" <axboe@kernel.dk>
Cc: "oren@nvidia.com" <oren@nvidia.com>,
"idanb@nvidia.com" <idanb@nvidia.com>,
"yossike@nvidia.com" <yossike@nvidia.com>
Subject: Re: [PATCH 1/1] null_blk: add option for managing virtual boundary
Date: Sun, 11 Apr 2021 23:34:44 +0000 [thread overview]
Message-ID: <BL0PR04MB65147B275F17A60AEA672651E7719@BL0PR04MB6514.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20210411162658.251456-1-mgurtovoy@nvidia.com
On 2021/04/12 1:30, Max Gurtovoy wrote:
> This will enable changing the virtual boundary of null blk devices. For
> now, null blk devices didn't have any restriction on the scatter/gather
> elements received from the block layer. Add a module parameter that will
> control the virtual boundary. This will enable testing the efficiency of
> the block layer bounce buffer in case a suitable application will send
> discontiguous IO to the given device.
>
> Initial testing with patched FIO showed the following results (64 jobs,
> 128 iodepth):
> IO size READ (virt=false) READ (virt=true) Write (virt=false) Write (virt=true)
> ---------- ------------------- ----------------- ------------------- -------------------
> 1k 10.7M 8482k 10.8M 8471k
> 2k 10.4M 8266k 10.4M 8271k
> 4k 10.4M 8274k 10.3M 8226k
> 8k 10.2M 8131k 9800k 7933k
> 16k 9567k 7764k 8081k 6828k
> 32k 8865k 7309k 5570k 5153k
> 64k 7695k 6586k 2682k 2617k
> 128k 5346k 5489k 1320k 1296k
>
> Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
> ---
> drivers/block/null_blk/main.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/block/null_blk/main.c b/drivers/block/null_blk/main.c
> index d6c821d48090..9ca80e38f7e5 100644
> --- a/drivers/block/null_blk/main.c
> +++ b/drivers/block/null_blk/main.c
> @@ -84,6 +84,10 @@ enum {
> NULL_Q_MQ = 2,
> };
>
> +static bool g_virt_boundary = false;
> +module_param_named(virt_boundary, g_virt_boundary, bool, 0444);
> +MODULE_PARM_DESC(virt_boundary, "Require a virtual boundary for the device. Default: False");
> +
> static int g_no_sched;
> module_param_named(no_sched, g_no_sched, int, 0444);
> MODULE_PARM_DESC(no_sched, "No io scheduler");
> @@ -1880,6 +1884,9 @@ static int null_add_dev(struct nullb_device *dev)
> BLK_DEF_MAX_SECTORS);
> blk_queue_max_hw_sectors(nullb->q, dev->max_sectors);
>
> + if (g_virt_boundary)
> + blk_queue_virt_boundary(nullb->q, PAGE_SIZE - 1);
> +
> null_config_discard(nullb);
>
> sprintf(nullb->disk_name, "nullb%d", nullb->index);
>
Looks good to me, but could you also add the configfs equivalent setting ?
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2021-04-11 23:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-11 16:26 [PATCH 1/1] null_blk: add option for managing virtual boundary Max Gurtovoy
2021-04-11 22:13 ` Chaitanya Kulkarni
2021-04-11 23:34 ` Damien Le Moal [this message]
2021-04-11 23:36 ` Damien Le Moal
2021-04-12 9:39 ` Max Gurtovoy
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=BL0PR04MB65147B275F17A60AEA672651E7719@BL0PR04MB6514.namprd04.prod.outlook.com \
--to=damien.lemoal@wdc.com \
--cc=axboe@kernel.dk \
--cc=idanb@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mgurtovoy@nvidia.com \
--cc=oren@nvidia.com \
--cc=yossike@nvidia.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;
as well as URLs for NNTP newsgroup(s).