CFQ considers it seeky (*), BFQ doesn't. As a side effect BFQ does not
always dispatch enough requests to correctly detect tagging.
At the first seek you cannot tell if the process is going to bee seeky
or not, and we have chosen to consider it sequential because it improved
fairness in some sequential workloads (the CIC_SEEKY heuristic is used
also to determine the idle_window length in [bc]fq_arm_slice_timer()).
Anyway, we're dealing with heuristics, and they tend to favor some
workload over other ones. If recovering this thoughput loss is more
important than a transient unfairness due to short idling windows assigned
to sequential processes when they start, I've no problems in switching
the CIC_SEEKY logic to consider a process seeky when it starts.
Thank you for testing and for pointing out this issue, we missed it
in our testing.
(*) to be correct, the initial classification depends on the position
of the first accessed sector.
