[lkml]   [2020]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v5 7/7] locking/lockdep: Add a fast path for chain_hlocks allocation
On Mon, Feb 03, 2020 at 11:41:47AM -0500, Waiman Long wrote:
> When alloc_chain_hlocks() is called, the most likely scenario is
> to allocate from the primordial chain block which holds the whole
> chain_hlocks[] array initially. It is the primordial chain block if its
> size is bigger than MAX_LOCK_DEPTH. As long as the number of entries left
> after splitting is still bigger than MAX_CHAIN_BUCKETS it will remain
> in bucket 0. By splitting out a sub-block at the end, we only need to
> adjust the size without changing any of the existing linkage information.
> This optimized fast path can reduce the latency of allocation requests.
> This patch does change the order by which chain_hlocks entries are
> allocated. The original code allocates entries from the beginning of
> the array. Now it will be allocated from the end of the array backward.

Cute; but why do we care? Is there any measurable performance indicator?

 \ /
  Last update: 2020-02-04 13:48    [W:0.087 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site