On 2021/08/28 2:38, Phillip Susi wrote: > > Tim Walker <tim.t.walker@xxxxxxxxxxx> writes: > >> The IO Scheduler is a useful place to implement per-actuator load >> management, but with the LBA-to-actuator mapping available to user >> space (via sysfs) it could also be done at the user level. Or pretty >> much anywhere else where we have knowledge and control of the various >> streams. > > I suppose there may be some things user space could do with the > information, but mainly doesn't it have to be done in the IO scheduler? Correct, if the user does not use a file system then optimizations will depend on the user application and the IO scheduler. > As it stands now, it is going to try to avoid seeking between the two > regions even though the drive can service a contiguous stream from both > just fine, right? Correct. But any IO scheduler optimization will kick-in only and only if the user is accessing the drive at a queue depth beyond the drive max QD, 32 for SATA. If the drive is exercised at a QD less than its maximum, the scheduler does not hold on to requests (at least mq-deadline does not, not sure about bfq). So even with only this patch set (no optimizations at the kernel level), the user can still make things work as expected, that is, get multiple streams of IOs to execute in parallel. -- Damien Le Moal Western Digital Research
