Date: Fri, 28 Jun 2013 17:50:29 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, hackers@freebsd.org Subject: Re: b_freelist TAILQ/SLIST Message-ID: <CAJ-VmokbrS7qus%2BS4WY45gypX=VFYyZbwg6s-Fw_FbBArnQRnw@mail.gmail.com> In-Reply-To: <51CE0AF7.6090906@FreeBSD.org> References: <51CCAE14.6040504@FreeBSD.org> <20130628065732.GL91021@kib.kiev.ua> <51CE0AF7.6090906@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 June 2013 15:15, Alexander Motin <mav@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokbrS7qus%2BS4WY45gypX=VFYyZbwg6s-Fw_FbBArnQRnw>