GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler

[Francois Tigeot]

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