aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorJason Gunthorpe <jgg@mellanox.com>2020-03-10 10:22:37 +0200
committerJason Gunthorpe <jgg@mellanox.com>2020-03-13 11:08:02 -0300
commit1c78a21a0c6f8df98a2281c1c0232f9c85e1c44d (patch)
tree6a73a37cdf63d84d7b5294bf4a2fb8691df3c57f /tools/perf/scripts/python/export-to-postgresql.py
parentRDMA/mlx5: Fix locking in MR cache work queue (diff)
downloadwireguard-linux-1c78a21a0c6f8df98a2281c1c0232f9c85e1c44d.tar.xz
wireguard-linux-1c78a21a0c6f8df98a2281c1c0232f9c85e1c44d.zip
RDMA/mlx5: Revise how the hysteresis scheme works for cache filling
Currently if the work queue is running then it is in 'hysteresis' mode and will fill until the cache reaches the high water mark. This implicit state is very tricky and doesn't interact with pending very well. Instead of self re-scheduling the work queue after the add_keys() has started to create the new MR, have the queue scheduled from reg_mr_callback() only after the requested MR has been added. This avoids the bad design of an in-rush of queue'd work doing back to back add_keys() until EAGAIN then sleeping. The add_keys() will be paced one at a time as they complete, slowly filling up the cache. Also, fix pending to be only manipulated under lock. Link: https://lore.kernel.org/r/20200310082238.239865-12-leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions