summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorOmar Sandoval <osandov@fb.com>2016-09-17 12:20:54 -0700
committerJens Axboe <axboe@fb.com>2016-09-17 13:39:06 -0600
commit5c64a8df0ca88c79c9cb74674c2481e5f7ede511 (patch)
treea10aa8ab518921ee8f16511076a15ff2b64e52ec
parent05fd095d53b979878f016c3a7080d3683cc89d72 (diff)
downloadlinux-5c64a8df0ca88c79c9cb74674c2481e5f7ede511.tar.gz
linux-5c64a8df0ca88c79c9cb74674c2481e5f7ede511.tar.bz2
linux-5c64a8df0ca88c79c9cb74674c2481e5f7ede511.zip
sbitmap: don't update the allocation hint on clear after resize
If we have a bunch of high-numbered bits allocated and then we resize the struct sbitmap_queue, when those bits get cleared, we'll update the hint and then have to re-randomize it repeatedly. Avoid that by checking that the cleared bit is still a valid hint. No measurable performance difference in the common case. Signed-off-by: Omar Sandoval <osandov@fb.com> Signed-off-by: Jens Axboe <axboe@fb.com>
-rw-r--r--lib/sbitmap.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/lib/sbitmap.c b/lib/sbitmap.c
index f736c52a712c..e40808921544 100644
--- a/lib/sbitmap.c
+++ b/lib/sbitmap.c
@@ -321,7 +321,7 @@ void sbitmap_queue_clear(struct sbitmap_queue *sbq, unsigned int nr,
{
sbitmap_clear_bit(&sbq->sb, nr);
sbq_wake_up(sbq);
- if (likely(!sbq->round_robin))
+ if (likely(!sbq->round_robin && nr < sbq->sb.depth))
*per_cpu_ptr(sbq->alloc_hint, cpu) = nr;
}
EXPORT_SYMBOL_GPL(sbitmap_queue_clear);