diff options
| author | Leon Romanovsky <leonro@mellanox.com> | 2015-10-21 09:21:17 +0300 |
|---|---|---|
| committer | Doug Ledford <dledford@redhat.com> | 2015-12-08 16:55:31 -0500 |
| commit | ab5cdc31630c7596d81ca8fbe7d695f10666f39b (patch) | |
| tree | c544b85a8b79e6bf9d1f57dc8eaf63df58b3154c /drivers/infiniband | |
| parent | 0ef2f05c7e02ff99c0b5b583d7dee2cd12b053f2 (diff) | |
| download | op-kernel-dev-ab5cdc31630c7596d81ca8fbe7d695f10666f39b.zip op-kernel-dev-ab5cdc31630c7596d81ca8fbe7d695f10666f39b.tar.gz | |
IB/mlx5: Postpone remove_keys under knowledge of coming preemption
The remove_keys() logic is performed as garbage collection task. Such
task is intended to be run when no other active processes are running.
The need_resched() will return TRUE if there are user tasks to be
activated in near future.
In such case, we don't execute remove_keys() and postpone
the garbage collection work to try to run in next cycle,
in order to free CPU resources to other tasks.
The possible pseudo-code to trigger such scenario:
1. Allocate a lot of MR to fill the cache above the limit.
2. Wait a small amount of time "to calm" the system.
3. Start CPU extensive operations on multi-node cluster.
4. Expect performance degradation during MR cache shrink operation.
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Diffstat (limited to 'drivers/infiniband')
| -rw-r--r-- | drivers/infiniband/hw/mlx5/mr.c | 14 |
1 files changed, 13 insertions, 1 deletions
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c index ec8993a..6000f7a 100644 --- a/drivers/infiniband/hw/mlx5/mr.c +++ b/drivers/infiniband/hw/mlx5/mr.c @@ -381,7 +381,19 @@ static void __cache_work_func(struct mlx5_cache_ent *ent) } } } else if (ent->cur > 2 * ent->limit) { - if (!someone_adding(cache) && + /* + * The remove_keys() logic is performed as garbage collection + * task. Such task is intended to be run when no other active + * processes are running. + * + * The need_resched() will return TRUE if there are user tasks + * to be activated in near future. + * + * In such case, we don't execute remove_keys() and postpone + * the garbage collection work to try to run in next cycle, + * in order to free CPU resources to other tasks. + */ + if (!need_resched() && !someone_adding(cache) && time_after(jiffies, cache->last_add + 300 * HZ)) { remove_keys(dev, i, 1); if (ent->cur > ent->limit) |
