[0/3] Unify the throttling code for wbt and io-latency

Message

Josef Bacik Dec. 4, 2018, 5:59 p.m. UTC

Originally when I wrote io-latency and the rq_qos code to provide a common base
between wbt and io-latency I left out the throttling part.  These were basically
the same, but slightly different in both cases.  The difference was enough and
the code wasn't too complicated that I just copied it into io-latency and
modified it for what I needed and carried on.

Since then Jens has fixed a few issues with wakeups with the niave approach.
Before you could easily cycle waiters back to the end of the line if they were
woken up without the ability to actually do their IO yet.  But because this was
only in wbt we didn't get it in io-latency.

Resolve this by creating a unified interface for doing the throttling, and then
just handle the differences between the two users with user specific callbacks.
This allows us to have one place where we have to mess with wakeups, and gives
each user the ability to be their own special snowflake.

Jens, I based this on for-next from 12/03, let me know if you want a different
base.  I tested this with my blktests test.  Thanks,

Josef

Comments

Jens Axboe Dec. 5, 2018, 5:40 p.m. UTC | #1

On 12/4/18 10:59 AM, Josef Bacik wrote:
> Originally when I wrote io-latency and the rq_qos code to provide a common base
> between wbt and io-latency I left out the throttling part.  These were basically
> the same, but slightly different in both cases.  The difference was enough and
> the code wasn't too complicated that I just copied it into io-latency and
> modified it for what I needed and carried on.
> 
> Since then Jens has fixed a few issues with wakeups with the niave approach.
> Before you could easily cycle waiters back to the end of the line if they were
> woken up without the ability to actually do their IO yet.  But because this was
> only in wbt we didn't get it in io-latency.
> 
> Resolve this by creating a unified interface for doing the throttling, and then
> just handle the differences between the two users with user specific callbacks.
> This allows us to have one place where we have to mess with wakeups, and gives
> each user the ability to be their own special snowflake.
> 
> Jens, I based this on for-next from 12/03, let me know if you want a different
> base.  I tested this with my blktests test.  Thanks,

Applies fine to for-4.21/block, which is what I care about. Looks good to me,
applied, thanks.