... I put up the previous set of benchmarks: > > - The erratic behaviour from Linux is due ... jemalloc on NetBSD was, basically, > single threaded. That said it did show a ... datasize and stack size limits). Same benchmark config that Andrew is using, etc ...

netbsd-tech-kern - Kris Kennaway - Oct 5 2007 - 05:18

... I put up the previous set of benchmarks: > } > > } > - The erratic behaviour from Linux is due ... datasize and stack size limits). Same benchmark config that > } Andrew is using, etc ... reason for > } the jump at 19 threads (I only graphed a single run). ...

netbsd-tech-kern - Kris Kennaway - Oct 6 2007 - 05:02

... up the previous set of benchmarks: } > } > - The erratic behaviour from Linux ... and stack size limits). Same benchmark config that } Andrew is using ... the drop-off above 8 threads on FreeBSD is due to ... for } the jump at 19 threads (I only graphed a single ...

netbsd-tech-kern - John Nemeth - Oct 5 2007 - 21:48

On Oct 9, 2:34pm, tron@zhadum.org.uk (Matthias Scheler) wrote: -- Subject: Re: Thread benchmarks, round 2 | > cpu0 at mainbus0 apid 0: (boot processor) | > cpu0: Intel(R) Xeon(TM) CPU 3.40GHz, ...

netbsd-tech-kern - Christos Zoulas - Oct 9 2007 - 11:22

... I put up the previous set of benchmarks: - The erratic behaviour from Linux is due ... mistake jemalloc on NetBSD was, basically, single threaded. That said it did show a noticable ... , and changes to how I'm benchmarking the systems, I have rerun them. ...

netbsd-tech-kern - Andrew Doran - Oct 4 2007 - 19:04

... result :-) OK, I have repeated the benchmarking in two additional cases: 1) NetBSD ... This is using the new scheduler. 2) As above with experimental libc and ... speaking. In particular performance at 4 threads is still significantly below FreeBSD ...

netbsd-tech-kern - Kris Kennaway - Oct 5 2007 - 15:08

... the > >> default datasize and stack size limits). Same benchmark config that > >> Andrew is using, etc. > >> > ... been made to i386, particularly deferred address space switching. Threaded programs in particular are much slower on amd64 for that ...

netbsd-tech-kern - Andrew Doran - Oct 5 2007 - 14:05

... them in the kernel? Switching the CPU offline with cpuctl keeps the execution of bound threads only. At this moment, it should be OK for the benchmarking. -- Best regards, Mindaugas www.NetBSD.org

netbsd-tech-kern - Mindaugas R. - Oct 6 2007 - 12:51

... the kernel? > > Switching the CPU offline with cpuctl keeps the execution of bound threads > only. At this moment, it should be OK for the benchmarking. > Except it didn't work, as above ;-) Kris

netbsd-tech-kern - Kris Kennaway - Oct 6 2007 - 13:35

... > OK, I have repeated the benchmarking in two additional cases: > > 1) NetBSD ... This is using the new scheduler. > > 2) As above with experimental libc and ... speaking. In > particular performance at 4 threads is still significantly below FreeBSD ...

netbsd-tech-kern - Andrew Doran - Oct 5 2007 - 15:39

... >> OK, I have repeated the benchmarking in two additional cases: >> >> 1) NetBSD ... This is using the new scheduler. >> >> 2) As above with experimental libc and ... . In >> particular performance at 4 threads is still significantly below FreeBSD >> ...

netbsd-tech-kern - Kris Kennaway - Oct 5 2007 - 17:38

... > wrote: > Andrew Doran wrote: > > So, I learned a few things since I put up the previous set of benchmarks: > > > > - The erratic behaviour from Linux is due to the glibc memory allocator. > > Using Google's tcmalloc, the problem disappears. > > ...

netbsd-tech-kern - matthew sporleder - Oct 5 2007 - 09:18

... org> wrote: >> Andrew Doran wrote: >>> So, I learned a few things since I put up the previous set of >>> benchmarks: >>> >>> - The erratic behaviour from Linux is due to the glibc memory >>> allocator. >>> Using Google's tcmalloc, the problem ...

netbsd-tech-kern - Adam Hamsik - Oct 5 2007 - 10:35

... : > >> Andrew Doran wrote: > >>> So, I learned a few things since I put up the previous set of > >>> benchmarks: > >>> > >>> - The erratic behaviour from Linux is due to the glibc memory > >>> allocator. > >>> Using Google's tcmalloc, the problem ...

netbsd-tech-kern - matthew sporleder - Oct 5 2007 - 11:03

... > things from GENERIC.MP like I386_CPU support, etc, and removed the > default datasize and stack size limits). Same benchmark config that > Andrew is using, etc. > > http://people.freebsd.org/~kris/scaling/netbsd.png Is this system running ...

netbsd-tech-kern - Thor Lancelot Simon - Oct 5 2007 - 13:24

... >> things from GENERIC.MP like I386_CPU support, etc, and removed the >> default datasize and stack size limits). Same benchmark config that >> Andrew is using, etc. >> >> http://people.freebsd.org/~kris/scaling/netbsd.png > >Is this system ...

netbsd-tech-kern - Christos Zoulas - Oct 5 2007 - 13:53

... since I put up the previous set of > >>> benchmarks: > >>> > >>> - The erratic ... : If i really know, i can hack GPG KeyID: 1FCEDEA1 ________________________________________________ Message sent using UebiMiau 2.7.2

netbsd-tech-kern - Rodrigo Rubira Branco (BSDaemon) - Oct 5 2007 - 11:51

... >> things from GENERIC.MP like I386_CPU support, etc, and removed the >> default datasize and stack size limits). Same benchmark config that >> Andrew is using, etc. >> >> http://people.freebsd.org/~kris/scaling/netbsd.png > > Is this system ...

netbsd-tech-kern - Kris Kennaway - Oct 5 2007 - 14:18

... > wrote: >> Andrew Doran wrote: >>> So, I learned a few things since I put up the previous set of benchmarks: >>> >>> - The erratic behaviour from Linux is due to the glibc memory allocator. >>> Using Google's tcmalloc, the problem disappears. >> ...

netbsd-tech-kern - Kris Kennaway - Oct 5 2007 - 14:28

On Fri, Oct 05, 2007 at 06:48:10PM -0700, John Nemeth wrote: > > Up above, you said that you used HEAD. In NetBSD, HEAD is still > big lock / giant lock with only some minor exceptions. Really? What did you think Andy's been working on all

netbsd-tech-kern - Thor Lancelot Simon - Oct 6 2007 - 08:02