Andrew Doran wrote:
> On Fri, Oct 05, 2007 at 09:08:07PM +0200, Kris Kennaway wrote:
> 
>> OK, I have repeated the benchmarking in two additional cases:
>>
>> 1) NetBSD with 8 CPUs and some kind of experimental kernel that Andrew 
>> gave me (based on the vmlocking branch).  This is using the new scheduler.
>>
>> 2) As above with experimental libc and libpthread also given to me by 
>> Andrew.  I dunno what changes these contain either :)
> 
> It's actually GENERIC.MP from current, with SCHED_M2. No vmlocking code
> involved - would you be able to update the labels? The libc has jemalloc,
> and libpthread is simply an up to date copy.

Done.

>> I was only able to run in the 8 CPU configuration because when I tried 
>> to disable CPUs with cpuctl, processes would hang under load.  This is 
>> probably a scheduler issue.
> 
> Right, I doubt that bit has been well tested since the scheduler is so new.
>  
>>   http://people.freebsd.org/~kris/scaling/netbsd.png
>>
>> This shows some improvement but not much, relatively speaking.  In 
>> particular performance at 4 threads is still significantly below FreeBSD 
>> performance, which (given what I measured previously) suggests that 
>> there is still a performance deficit with 4 CPUs on NetBSD.  It would be 
>> nice to be able to test this directly though, maybe Andrew can give me a 
>> kernel that has MAXCPU=4 or whatever the NetBSD version is.
> 
> Interesting. :-). Thanks for running this. I'm still optimistic about the 4
> CPU case so I'm very interested in seeing what the results would be. I'll
> have a look into the offline problem this evening.

OK thanks.

In the meantime I ran sysbench with postgresql 8.2.  Same NetBSD configs 
as before (except I built my own kernel with the sched_m2 patches since 
I needed to tweak the sysv ipc parameters).

   http://people.freebsd.org/~kris/scaling/netbsd-pgsql.png

postgresql is much more scalable than mysql on this workload and doesn't 
have silly scaling bottlenecks inside the application (cf the tail of 
the FreeBSD curve for mysql which is where pthread mutex contention 
kicked in).

Kris