b_freelist TAILQ/SLIST

[Adrian Chadd]

On 28 June 2013 15:15, Alexander Motin <mav at freebsd.org> wrote:

> I think it indeed may be a cache trashing. I've made some profiling for
> getpbuf()/relpbuf() and found interesting results. With patched kernel using
> SLIST profiling shows mostly one point of RESOURCE_STALLS.ANY in relpbuf()
> -- first lock acquisition causes 78% of them. Later memory accesses
> including the lock release are hitting the same cache line and almost free.
> With "clean" kernel using TAILQ I see RESOURCE_STALLS.ANY spread almost
> equally between lock acquisition, bswlist access and lock release. It looks
> like the cache line is constantly erased by something.

Can you narrow down the resource stall check to each of the sub-types?
See which one/ones it is?


-adrian