linux-kernel - Re: [PATCH] iosched: Add i10 I/O Scheduler

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <0cce60db-5a41-2e1b-ba5d-7905966bec25@grimberg.me>
Date:   Mon, 30 Nov 2020 11:20:30 -0800
From:   Sagi Grimberg <sagi@...mberg.me>
To:     Rachit Agarwal <rach4x0r@...il.com>
Cc:     Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
        linux-block@...r.kernel.org, linux-nvme@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Keith Busch <kbusch@...nel.org>,
        Ming Lei <ming.lei@...hat.com>,
        Jaehyun Hwang <jaehyun.hwang@...nell.edu>,
        Qizhe Cai <qc228@...nell.edu>,
        Midhul Vuppalapati <mvv25@...nell.edu>,
        Sagi Grimberg <sagi@...htbitslabs.com>,
        Rachit Agarwal <ragarwal@...nell.edu>
Subject: Re: [PATCH] iosched: Add i10 I/O Scheduler


> Dear all:
> 
> Thanks, again, for the very constructive decisions.
> 
> I am writing back with quite a few updates:
> 
> 1. We have now included a detailed comparison of i10 scheduler with 
> Kyber with NVMe-over-TCP 
> (https://github.com/i10-kernel/upstream-linux/blob/master/i10-evaluation.pdf). 
> In a nutshell, when operating with NVMe-over-TCP, i10 demonstrates the 
> core tradeoff: higher latency, but also higher throughput. This seems to 
> be the core tradeoff exposed by i10.
> 
> 2. We have now implemented an adaptive version of i10 I/O scheduler, 
> that uses the number of outstanding requests at the time of batch 
> dispatch (and whether the dispatch was triggered by timeout or not) to 
> adaptively set the batching size. The new results 
> (https://github.com/i10-kernel/upstream-linux/blob/master/i10-evaluation.pdf) 
> show that i10-adaptive further improves performance for low loads, while 
> keeping the performance for high loads. IMO, there is much to do on 
> designing improved adaptation algorithms.
> 
> 3. We have now updated the i10-evaluation document to include results 
> for local storage access. The core take-away here is that i10-adaptive 
> can achieve similar throughput and latency at low loads and at high 
> loads when compared to noop, but still requires more work for lower 
> loads. However, given that the tradeoff exposed by i10 scheduler is 
> particularly useful for remote storage devices (and as Jens suggested, 
> perhaps for virtualized local storage access), I do agree with Sagi -- I 
> think we should consider including it in the core, since this may be 
> useful for a broad range of new use cases.
> 
> We have also created a second version of the patch that includes these 
> updates: 
> https://github.com/i10-kernel/upstream-linux/blob/master/0002-iosched-Add-i10-I-O-Scheduler.patch
> 
> As always, thank you for the constructive discussion and I look forward 
> to working with you on this.

Thanks Rachit,

Would be good if you can send a formal patch for the adaptive queuing so
people can have a look.

One thing that was left on the table is weather this should be a full
blown scheduler or a core block infrastructure that would either be
set on-demand or by default.

I think that Jens and Ming expressed that this should be something that
we should place this in the block core, but I'd like to hear maybe
Ming can elaborate on his ideas how to do this.