Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <57accb2a-828d-c532-d964-130a63faebe5@acm.org>
Date:   Sun, 24 Jul 2022 18:48:44 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH v2 2/2] block/mq-deadline: Prioritize first request
Content-Language: en-US
To:     Wang You <wangyoua@uniontech.com>
Cc:     axboe@kernel.dk, fio@vger.kernel.org, hch@lst.de,
        jaegeuk@kernel.org, linux-block@vger.kernel.org,
        linux-kernel@vger.kernel.org, ming.lei@redhat.com,
        wangxiaohua@uniontech.com
References: <f798c875-0bb9-add7-d7a3-4ac2a76e85d9@acm.org>
 <20220723105909.440050-1-wangyoua@uniontech.com>
From:   Bart Van Assche <bvanassche@acm.org>
In-Reply-To: <20220723105909.440050-1-wangyoua@uniontech.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 7/23/22 03:59, Wang You wrote:
> Also, can I ask? If using fio or other tools, how should testing be done to get
> more accurate and convincing data? Such as the perfectly sequential and random I/O
> performance you mentioned above (fio's multi-threaded test does result in neither
> perfectly sequential nor perfectly random, but single thread dispatch is too slow,
> and cannot play the merge and sorting ability of elv).

I'm not sure that there is agreement about for which data patterns to 
measure performance to conclude that certain code changes improve 
performance of an I/O scheduler.

Thanks,

Bart.