xeon 2.8GHz SMP/NOT test results

[John Baldwin]

On Tuesday 17 October 2006 00:36, Duane Whitty wrote:
> On Mon, Oct 16, 2006 at 01:01:29PM +0200, Attilio Rao wrote:
> > 2006/10/16, Ivan Voras <ivoras at fer.hr>:
> > >Kian Mohageri wrote:
> > >
> > >> I've never used sysbench (I essentially picked it randomly) so if you 
> > >know
> > >> it to be a crappy benchmark tool for this sort of thing, do tell.  I'm 
> > >also
> > >> pretty new at testing performance in general, but I hope someone finds 
it
> > >> useful anyway.
> > >
> > >Maybe you'll be interested in ports/benchmark/unixbench, especially the
> > >context switch and shell scripts benchmarks?
> > >
> > >> http://www.zampanosbits.com/smp_tests/
> > >
> > >Interesting results, especially for such an early version of the
> > >processor (wrt HTT) - I'd expect much lower gain from HTT. While you're
> > >at it, maybe you could add more results to your benchmark, like change
> > >the timecounter to TSC, use various gcc optimization flags, twiddle
> > >machdep.cpu_idle_hlt, use SMP kernel with HTT disabled in BIOS?
> > 
> > What about PREEMPTION/FULL_PREEMPTION?
> > 
> > Attilio
> > 
> > 
> > -- 
> > Peace can only be achieved by understanding - A. Einstein
> > _______________________________________________
> 
> If the becnhmarks are being done to measure performance then
> would not FULL_PREEMPTION be contra-indicated as it is a 
> debugging option?
> 
> >From /usr/src/sys/conf/NOTES
> 
> # FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel
> #         threads.  Its sole use is to expose race conditions and other
> #         bugs during development.  Enabling this option will reduce
> #         performance and increase the frequency of kernel panics by
> #         design.  If you aren't sure that you need it then you don't.
> #         Relies on the PREEMPTION option.  DON'T TURN THIS ON.
> 
> Is there something happening I do not understand?

As it says, don't use it, just use 'PREEMPTION'.

-- 
John Baldwin