A process with such a low throughput would be marked as seeky from
the heuristics implemented in cfq/bfq. Seeky processes are not
treated in the same way as sequential ones and they should not get
their full slice allocated, since they idle only for very short
BTW looking at the code they can get a full slice, if they always
reissue requests fast enough - within BFQ_MIN_TT - and this is
definitely an issue/error in the current implementation (and we
didn't notice it when converting the code from time-based to
service-based allocation :) ).
An easy solution (without changing the nature of bfq) would be
to use shorter slices for seeky queues, with the same mechanism
we already use for the async ones.