On Mon, 24 Nov 2008, Attilio Rao wrote:
2008/11/23, Alexander Leidinger <[EMAIL PROTECTED]>:
Quoting Attilio Rao <[EMAIL PROTECTED]> (from Sun, 23 Nov 2008 14:02:22
+0100):
pmcannotate is a tool that prints out sources of a tool (in C or
assembly) with inlined profiling informations retriev
On Wed, 12 Mar 2008, Ivan Voras wrote:
On 12/03/2008, Mark Kirkwood <[EMAIL PROTECTED]> wrote:
Hmm - somehow read right past the bit where you say you have a 512MB
cache - sorry! However, worth checking it is set to write-back rather
than write-through.
As far as I can see it is set to wr
On Wed, 2 Jan 2008, Bruce Evans wrote:
On Tue, 1 Jan 2008, Jeff Roberson wrote:
On Tue, 1 Jan 2008, Gergely CZUCZY wrote:
There's this SYSCALL CPU extension with the SYSENTER/SYSEXIT features.
IIRC
Linux takes advantage of this, while FreeBSD doesn't. I might be wrong
here,
On Tue, 1 Jan 2008, Gergely CZUCZY wrote:
On Tue, Jan 01, 2008 at 05:04:56AM +0100, Kris Kennaway wrote:
Ivan Voras wrote:
Kris Kennaway wrote:
Gergely CZUCZY wrote:
It looks like myisam is doing huge numbers of concurrent reads of the
same file which is running into exclusive locking in the
On Sat, 1 Dec 2007, Gergely CZUCZY wrote:
On Sat, Dec 01, 2007 at 04:06:55PM -0500, Mike Tancsa wrote:
At 03:56 PM 12/1/2007, Gergely CZUCZY wrote:
I don't quite understand the question. It's the very same box, with
a dualboot configuration.
Fire up the 3ware controller's RAID management sof
I've forwarded this mail to the freebsd performance list so more people
can take a look at it. Thanks for all of the details. What was the test
that you're doing? sysbench? With writes or without? Or some other
benchmark?
Thanks,
Jeff
On Thu, 29 Nov 2007, Gergely CZUCZY wrote:
Hello
I
On Tue, 6 Nov 2007, Josh Carroll wrote:
That's expected due to the fuzzy rounding of 128 / 10, etc. Can you set
slice_min and slice both equal to 7 and see if the numbers come out
better than without the patch but with a slice value of 7? Basically I'm
trying to isolate the effects of the diff
On Mon, 5 Nov 2007, Josh Carroll wrote:
Turns out the last patch I posted had a small compile error because I
edited it by hand to remove one section. Here's an updated patch that
fixes that and changes the min/max slice values to something more
reasonable. Slice min should be around 4 with a
On Sun, 4 Nov 2007, Josh Carroll wrote:
Josh, I included one too many changes in the diff and it made the results
ambiguous. I've scaled it back slightly by removing the changes to
sched_pickcpu() and included the patch in this email again. Can you run
through your tests once more? I'd like t
On Sun, 4 Nov 2007, Gelsema, P (Patrick) - FreeBSD wrote:
Hi Jeff,
I tried your patch. Ran a buildkernel, timed. Recompiled kernel including
your patch, rebooted and reran. Please find results below.
w/o patch
hulk# time make -j8 buildkernel
837.808u 138.167s 10:28.96 155.1% 6349+1349k 2
On Sun, 4 Nov 2007, Josh Carroll wrote:
Josh, thanks for your help so far. This has been very useful.
You're welcome, glad to help! Thanks for the effort and the patch.
Any testing you can run this through is appreciated. Anyone else lurking
in this thread who would like to is also welcome
On Sat, 3 Nov 2007, Josh Carroll wrote:
What would be interesting to know is if the sum of the temperatures is any
different. 4BSD gets a much more random distribution of load because a
thread is run on whatever cpu context switches next. ULE will have
specific load patterns since it scans lis
On Sat, 3 Nov 2007, Josh Carroll wrote:
What was the -j value and number of processors?
-j 8.
I did the following (one warm up, 3 times in a row after that, averaged):
cd /usr/src
rm -rf /usr/obj/*
make clean
time make -j8 -DNOCLEAN buildworld
The system is a Q6600, so 4 cores.
Josh, than
On Sat, 3 Nov 2007, Josh Carroll wrote:
buildworld isn't cooperating for me, but once I iron that out, I'll
post some results there as well :)
I was able to get buildworld compiling ok and here are the results:
4BSDULE.13ULE.7
13:24.7313:44.2813:38.85
Only a 1.75% dif
On Fri, 2 Nov 2007, Josh Carroll wrote:
Could you try spot checking a couple of tests with kern.sched.slice set to
half its present value? 4BSD on average will use half the slice that ULE
will by default.
The initial value was 13, and I changed it to 7. Here is the time
result for the ffmpeg
On Thu, 25 Oct 2007, Josh Carroll wrote:
I'm confident that we can improve things. It will probably not make the
cut for 7.0 since it will be too disruptive. I'm sure it can be
backported before 7.1 when ULE is likely to become the default.
That sounds great! I figured it was something that
On Wed, 24 Oct 2007, Josh Carroll wrote:
Your tests with ffmpeg threads vs processes probably is triggering more
context switches due to lock contention in the kernel in the threads case.
This is also likely the problem with some super-smack tests. On each
context switch 4BSD has an opportunity
On Tue, 23 Oct 2007, Josh Carroll wrote:
Hello,
I posted this to the stable mailing list, as I thought it was
pertinent there, but I think it will get better attention here. So I
apologize in advance for cross-posting if this is a faux pas. :)
Anyway, in summary, ULE is about 5-6 % slower than
I fixed a major bug in SCHED_SMP that impacted some users causing bad
performance and invalid load counts. Attilio also added support for i386
based machines. I have tested on UP which works although INVARIANTS and
WITNESS don't work properly on UP kernels. Single processor SMP kernels
work
I'm forwarding this email that I sent to current@ in the hopes that some
performance minded people will tell me their results with this new
scheduler infrastructure.
Thanks,
Jeff
-- Forwarded message --
Date: Tue, 12 Jun 2007 19:28:39 -0700 (PDT)
From: Jeff Roberson &l
In case any of you missed it, I sent this mail to [EMAIL PROTECTED] Please keep the
discussion there.
Thanks,
Jeff
-- Forwarded message --
Date: Sun, 20 May 2007 16:07:53 -0700 (PDT)
From: Jeff Roberson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: sche
21 matches
Mail list logo
