On Sat, Jul 28, 2012 at 05:55:06PM +0300, Mihai Carabas wrote: > > Thanks ftigeot for giving me access to a dual-socket opteron (2 cpus). The > results of testing: > > ############ enable smt ######## > kern.usched_bsd4.smt_enable: 0 -> 1 > tps = 11505.350032 (including connections establishing) > tps = 12358.802902 (including connections establishing) > tps = 10376.294593 (including connections establishing) > tps = 10329.976654 (including connections establishing) > tps = 11552.765499 (including connections establishing) > ------------------------------------------------------ > average = 11224 tps > > ############ disable smt ######## > kern.usched_bsd4.smt_enable: 1 -> 0 > tps = 8950.803833 (including connections establishing) > tps = 9573.479233 (including connections establishing) > tps = 8872.650887 (including connections establishing) > tps = 10609.939778 (including connections establishing) > tps = 10686.083868 (including connections establishing) > ------------------------------------------------------- > average = 9738 tps > > The command used was: > pgbench -U pgsql -j 2 -c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | > grep "including connections establishing" > > As you can see there is an important improvement. The results aren't so > constant (because of the heuristic way of scheduling - at the end of the > GSOC I will put online all my discussions with Alex and Matthew regarding > the problems of scheduling).
This machine is an old-school dual-Opteron 252 system and doesn't have any hyperthreading support at all. Its exact configuration is - 2 sockets - 1 core per socket (2.6 GHz, 1MB cache) - 2GB of RAM per socket - 1 thread per core Having an hyperthreading-aware scheduler shouldn't make any difference; what could explain the above performance differences ? -- Francois Tigeot
