Date: Tue, 24 Jan 2017 12:44:25 -0600 From: Eric van Gyzen <vangyzen@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au> Cc: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-stable@FreeBSD.org, svn-src-stable-10@FreeBSD.org Subject: Re: svn commit: r312666 - stable/10/sys/kern Message-ID: <0f2c3b59-54d3-a83a-29ba-4fcda2db25f2@FreeBSD.org> In-Reply-To: <d0970738-8eb7-8a81-453f-199f11fd2e39@FreeBSD.org> References: <201701230834.v0N8Ypnu011042@repo.freebsd.org> <20170124002712.Q903@besplex.bde.org> <49838a2b-c628-da8c-4c9c-4a66c83119f8@FreeBSD.org> <d0970738-8eb7-8a81-453f-199f11fd2e39@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/23/2017 12:12, Eric van Gyzen wrote: > On 01/23/2017 10:03, Andriy Gapon wrote: >> On 23/01/2017 15:34, Bruce Evans wrote: >>> What is a good benchmark for showing that the fix helps? >> >> Honestly, I do not know. We ran into a pathology where a thread was not getting >> scheduled for a long time after being preempted while in a critical section (so >> the actual preemption was a voluntary switch when exiting the critical section). >> I am not sure what kind of a synthetic benchmark or a test case would readily >> demonstrate the problem. > > I submitted r270423, which introduced the bug Andriy just fixed. I'm > already setting up the performance test that I used for that change. > It's a macro-benchmark of a commercial product, so I can't elaborate on > details, but at least I can give a thumb indication in the style of a > Roman Dictator. My performance tests showed no change, so although r312666 does not improve performance under my workload, it also does not hurt. Specifically, it does not reintroduce the regression introduced in r239157 that I poorly fixed in r270423. Thanks again for the fix, Andriy. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0f2c3b59-54d3-a83a-29ba-4fcda2db25f2>