summaryrefslogtreecommitdiffstats
path: root/mm/memory.c
diff options
context:
space:
mode:
authorJosef Bacik <jbacik@fb.com>2018-07-03 17:14:55 +0200
committerJens Axboe <axboe@kernel.dk>2018-07-09 17:07:54 +0200
commitd09d8df3a29403693d9d20cc34ed101f2c558e2b (patch)
treeef13236fd3cab8b7a3d6c27a7484862561afcd32 /mm/memory.c
parentswap,blkcg: issue swap io with the appropriate context (diff)
downloadlinux-d09d8df3a29403693d9d20cc34ed101f2c558e2b.tar.xz
linux-d09d8df3a29403693d9d20cc34ed101f2c558e2b.zip
blkcg: add generic throttling mechanism
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@fb.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'mm/memory.c')
0 files changed, 0 insertions, 0 deletions