On Tue, Jun 05, 2018 at 09:29:41AM -0400, Josef Bacik wrote: > From: Josef Bacik <jbacik@xxxxxx> > > Since IO can be issued from literally anywhere it's almost impossible to > do throttling without having some sort of adverse effect somewhere else > in the system because of locking or other dependencies. The best way to > solve this is to do the throttling when we know we aren't holding any > other kernel resources. Do this by tracking throttling in a per-blkg > basis, and if we require throttling flag the task that it needs to check > before it returns to user space and possibly sleep there. > > This is to address the case where a process is doing work that is > generating IO that can't be throttled, whether that is directly with a > lot of REQ_META IO, or indirectly by allocating so much memory that it > is swamping the disk with REQ_SWAP. We can't use task_add_work as we > don't want to induce a memory allocation in the IO path, so simply > saving the request queue in the task and flagging it to do the > notify_resume thing achieves the same result without the overhead of a > memory allocation. > > Signed-off-by: Josef Bacik <jbacik@xxxxxx> Acked-by: Tejun Heo <tj@xxxxxxxxxx> -- tejun
