Has anyone got numbers for overhead costs associated with using geom to
strip across LUNs? I am particularly interested in latency increases, CPU
costs, and any known throughput limitations. We're running FreeBSD 6.2. If
there are any other issues associated with using it in production I'd really
l
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
> 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 to perfectly balance the CPUs. ULE
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
On 10/24/07, Josh Carroll <[EMAIL PROTECTED]> wrote:
>
> > Yes, that's the proper default. You could try setting steal_thresh to 1.
> I
> > noticed a problem with building ports on an 8 core Xeon system while 8
> > distributed.net crunchers were running. The port build would proceed
> > incredibly
On Tue, 23 Oct 2007, Kris Kennaway wrote:
Josh Carroll wrote:
Anyway, in summary, ULE is about 5-6 % slower than 4BSD for two
workloads that I am sensitive to: building world with -j X, and ffmpeg
-threads X. Other benchmarks seem to indicate relatively equal
performance between the two. MySQL,
> Yes, that's the proper default. You could try setting steal_thresh to 1. I
> noticed a problem with building ports on an 8 core Xeon system while 8
> distributed.net crunchers were running. The port build would proceed
> incredibly slowly, steal_thresh=1 helped a little bit. It might not make up
On Wed, 24 Oct 2007 09:39:29 -0400
"Josh Carroll" <[EMAIL PROTECTED]> wrote:
> > 5-6% is a lot. ULE has some tuning for makeworld in -current, which
> > for me reduced it to less than 1% slower than 4BSD (down from 5-10%
> > slower), for the case of makeworld -j4 over nfs on a 2-CPU system with
>
On Wed, 24 Oct 2007 11:39:52 -0400
"Josh Carroll" <[EMAIL PROTECTED]> wrote:
> > kern.sched.steal_thresh is/was one of the more effective tuning sysctls.
> > rev 1.205 of sched_ule had a change that was supposed to automatically
> > adjust it based on the number of cores. Is this the same 8 core s
> kern.sched.steal_thresh is/was one of the more effective tuning sysctls. rev
> 1.205 of sched_ule had a change that was supposed to automatically adjust it
> based on the number of cores. Is this the same 8 core system as the
> other thread? In that case the commit dictates steal_thresh should be
At Tue, 23 Oct 2007 21:06:39 -0400,
Josh Carroll wrote:
>
> I decided to do some testing of concurrent processes (rather than a
> single process that's multi-threaded). Specifically, I ran 4 ffmpeg
> (without the -threads option) commands at the same time. The
> difference was less than a percent:
> 5-6% is a lot. ULE has some tuning for makeworld in -current, which
> for me reduced it to less than 1% slower than 4BSD (down from 5-10%
> slower), for the case of makeworld -j4 over nfs on a 2-CPU system with
> the sources pre-cached on the server and objects on a local file system,
> and exte
12 matches
Mail list logo
