Date: Thu, 15 Dec 2011 17:26:04 +0100 From: Attilio Rao <attilio@freebsd.org> To: Mike Tancsa <mike@sentex.net> Cc: Ivan Klymenko <fidaj@ukr.net>, mdf@freebsd.org, Doug Barton <dougb@freebsd.org>, freebsd-stable@freebsd.org, Jilles Tjoelker <jilles@stack.nl>, "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de>, Current FreeBSD <freebsd-current@freebsd.org>, freebsd-performance@freebsd.org Subject: Re: SCHED_ULE should not be the default Message-ID: <CAJ-FndBP1C5W-LAB4QF-ro%2BuaEaTx7ZzAAS3nXFY_82WXt53YQ@mail.gmail.com> In-Reply-To: <4EE8D607.1000504@sentex.net> References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com> <4EE6060D.5060201@mail.zedat.fu-berlin.de> <4EE69C5A.3090005@FreeBSD.org> <20111213104048.40f3e3de@nonamehost.> <20111213230441.GB42285@stack.nl> <4ee7e2d3.0a3c640a.4617.4a33SMTPIN_ADDED@mx.google.com> <CAMBSHm89SkzGVgk9kNwBQoR62pXKjhJ%2BqXJK0qwC20r9p%2Bu-bw@mail.gmail.com> <4EE8D607.1000504@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/12/14 Mike Tancsa <mike@sentex.net>: > On 12/13/2011 7:01 PM, mdf@freebsd.org wrote: >> >> Has anyone experiencing problems tried to set sysctl kern.sched.steal_th= resh=3D1 ? >> >> I don't remember what our specific problem at $WORK was, perhaps it >> was just interrupt threads not getting serviced fast enough, but we've >> hard-coded this to 1 and removed the code that sets it in >> sched_initticks(). =C2=A0The same effect should be had by setting the >> sysctl after a box is up. > > FWIW, this does impact the performance of pbzip2 on an i7. Using a 1.1G f= ile > > pbzip2 -v -c big > /dev/null > > with burnP6 running in the background, > > sysctl kern.sched.steal_thresh=3D1 > vs > sysctl kern.sched.steal_thresh=3D3 > > > > =C2=A0 =C2=A0N =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Min =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Max =C2=A0 =C2=A0 =C2=A0 =C2=A0Median =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Avg =C2=A0 =C2=A0 =C2=A0 =C2=A0Stddev > x =C2=A010 =C2=A0 =C2=A0 38.005022 =C2=A0 =C2=A0 =C2=A038.42238 =C2=A0 = =C2=A0 38.194648 =C2=A0 =C2=A0 38.165052 =C2=A0 =C2=A00.15546188 > + =C2=A0 9 =C2=A0 =C2=A0 38.695417 =C2=A0 =C2=A0 40.595544 =C2=A0 =C2=A0 = 39.392127 =C2=A0 =C2=A0 39.435384 =C2=A0 =C2=A00.59814114 > Difference at 95.0% confidence > =C2=A0 =C2=A0 =C2=A0 =C2=A01.27033 +/- 0.412636 > =C2=A0 =C2=A0 =C2=A0 =C2=A03.32852% +/- 1.08119% > =C2=A0 =C2=A0 =C2=A0 =C2=A0(Student's t, pooled s =3D 0.425627) > > a value of 1 is *slightly* faster. Hi Mike, was that just the same codebase with the switch SCHED_4BSD/SCHED_ULE? Also, the results here should be in the 3% interval for the avg case, which is not yet at the 'alarm level' but could still be an indication. I still suspect I/O plays a big role here, however, thus it could be detemined by other factors. Could you retry the bench checking CPU usage and possible thread migration around for both cases? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndBP1C5W-LAB4QF-ro%2BuaEaTx7ZzAAS3nXFY_82WXt53YQ>