Not to beat a dead horse, but ...

[George Mitchell]

When I run this command on 10-STABLE on a uniprocessor system while
running the misc/dnetc port:

cd /usr/src
time make buildworld && time make buildkernel && time make installkernel

On revision 266422 with SCHED_ULE, I get (showing the time lines only):

7045.988u 897.681s 4:00:33.89 55.0%     29430+492k 27927+17003io 
30943pf+519w
1155.683u 149.422s 52:49.60 41.1%       25418+410k 7452+20843io 12166pf+248w
7.101u 4.838s 8:03.57 2.4%      5905+221k 1179+9461io 1345pf+67w

On revision 267211 with SCHED_4BSD:

6950.087u 665.074s 2:40:36.19 79.0%     29929+502k 33651+17368io 
31151pf+151w
1148.066u 134.312s 26:40.95 80.1%       26234+426k 9681+24613io 11917pf+106w
6.774u 4.369s 0:33.90 32.8%     3110+320k 1388+10979io 1514pf+3w

Since the majority of my systems are uniprocessors and I like to
run dnetc, SCHED_ULE has been a dealbreaker for me since day one.
Consequently I can't use freebsd_update.

The party line seems to be, "Well, everybody knows SCHED_ULE sucks
on uniprocessors."  Hello?  Not everybody has upgraded to multiple
core or hyperthreaded processors yet.  Do we really want to write
off every uniprocessor piece of hardware out here?

The other assertion I hear is that SCHED_ULE really excels on some
unspecified workload or other.  I'd love to see exactly how much
better it does than 4BSD on these mythological loads.    -- George