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_thresh=1 ? >> >> 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(). The 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 file > > pbzip2 -v -c big > /dev/null > > with burnP6 running in the background, > > sysctl kern.sched.steal_thresh=1 > vs > sysctl kern.sched.steal_thresh=3 > > > > N Min Max Median Avg Stddev > x 10 38.005022 38.42238 38.194648 38.165052 0.15546188 > + 9 38.695417 40.595544 39.392127 39.435384 0.59814114 > Difference at 95.0% confidence > 1.27033 +/- 0.412636 > 3.32852% +/- 1.08119% > (Student's t, pooled s = 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 -- 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>