On 28 June 2013 15:15, Alexander Motin <m...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
