lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 10 May 2020 00:44:53 -0700
From:   Sagi Grimberg <>
To:     Ming Lei <>,
        Baolin Wang <>
Cc:     Christoph Hellwig <>,,
        Ulf Hansson <>,
        Adrian Hunter <>,
        Arnd Bergmann <>,
        Linus Walleij <>,
        Paolo Valente <>,
        Orson Zhai <>,
        Chunyan Zhang <>,
        linux-mmc <>,
        linux-block <>,
        LKML <>
Subject: Re: [RFC PATCH v2 1/7] block: Extand commit_rqs() to do batch

>>>> You're mostly correct. This is exactly why an I/O scheduler may be
>>>> applicable here IMO. Mostly because I/O schedulers tend to optimize for
>>>> something specific and always present tradeoffs. Users need to
>>>> understand what they are optimizing for.
>>>> Hence I'd say this functionality can definitely be available to an I/O
>>>> scheduler should one exist.
>>> I guess it is just that there can be multiple requests available from
>>> scheduler queue. Actually it can be so for other non-nvme drivers in
>>> case of none, such as SCSI.
>>> Another way is to use one per-task list(such as plug list) to hold the
>>> requests for dispatch, then every drivers may see real .last flag, so they
>>> may get chance for optimizing batch queuing. I will think about the
>>> idea further and see if it is really doable.
>> How about my RFC v1 patch set[1], which allows dispatching more than
>> one request from the scheduler to support batch requests?
>> [1]
> Basically, my idea is to dequeue request one by one, and for each
> dequeued request:
> - we try to get a budget and driver tag, if both succeed, add the
> request to one per-task list which can be stored in stack variable,
> then continue to dequeue more request
> - if either budget or driver tag can't be allocated for this request,
> marks the last request in the per-task list as .last, and send the
> batching requests stored in the list to LLD
> - when queueing batching requests to LLD, if one request isn't queued
> to driver successfully, calling .commit_rqs() like before, meantime
> adding the remained requests in the per-task list back to scheduler
> queue or hctx->dispatch.

Sounds good to me.

> One issue is that this way might degrade sequential IO performance if
> the LLD just tells queue busy to blk-mq via return value of .queue_rq(),
> so I guess we still may need one flag, such as BLK_MQ_F_BATCHING_SUBMISSION.

Why is that degrading sequential I/O performance? because the specific
device will do better without batching submissions? If so, the driver
is not obligated to respect the bd->last/.commit_rqs, so if that is the
case, it should just ignore it.

Powered by blists - more mailing lists