Re: SCHED_ULE should not be the default

> On 12/12/2011 05:47, O. Hartmann wrote:
> > Do we have any proof at hand for such cases where SCHED_ULE performs
> > much better than SCHED_4BSD?
> 
> I complained about poor interactive performance of ULE in a desktop
> environment for years. I had numerous people try to help, including
> Jeff, with various tunables, dtrace'ing, etc. The cause of the problem
> was never found.
> 
> I switched to 4BSD, problem gone.
> 
> This is on 2 separate systems with core 2 duos.
> 
> 
> hth,
> 
> Doug
> 

If the algorithm ULE does not contain problems - it means the problem
has Core2Duo, or in a piece of code that uses the ULE scheduler.
I already wrote in a mailing list that specifically in my case (Core2Duo)
partially helps the following patch:
--- sched_ule.c.orig	2011-11-24 18:11:48.000000000 +0200
+++ sched_ule.c	2011-12-10 22:47:08.000000000 +0200
_at__at_ -794,7 +794,8 _at__at_
 	 * 1.5 * balance_interval.
 	 */
 	balance_ticks = max(balance_interval / 2, 1);
-	balance_ticks += random() % balance_interval;
+//	balance_ticks += random() % balance_interval;
+	balance_ticks += ((int)random()) % balance_interval;
 	if (smp_started == 0 || rebalance == 0)
 		return;
 	tdq = TDQ_SELF();
_at__at_ -2118,13 +2119,21 _at__at_
 	struct td_sched *ts;
 
 	THREAD_LOCK_ASSERT(td, MA_OWNED);
+	if (td->td_pri_class & PRI_FIFO_BIT)
+		return;
+	ts = td->td_sched;
+	/*
+	 * We used up one time slice.
+	 */
+	if (--ts->ts_slice > 0)
+		return;
 	tdq = TDQ_SELF();
 #ifdef SMP
 	/*
 	 * We run the long term load balancer infrequently on the first cpu.
 	 */
-	if (balance_tdq == tdq) {
-		if (balance_ticks && --balance_ticks == 0)
+	if (balance_ticks && --balance_ticks == 0) {
+		if (balance_tdq == tdq)
 			sched_balance();
 	}
 #endif
_at__at_ -2144,9 +2153,6 _at__at_
 		if (TAILQ_EMPTY(&tdq->tdq_timeshare.rq_queues[tdq->tdq_ridx]))
 			tdq->tdq_ridx = tdq->tdq_idx;
 	}
-	ts = td->td_sched;
-	if (td->td_pri_class & PRI_FIFO_BIT)
-		return;
 	if (PRI_BASE(td->td_pri_class) == PRI_TIMESHARE) {
 		/*
 		 * We used a tick; charge it to the thread so
_at__at_ -2157,11 +2163,6 _at__at_
 		sched_priority(td);
 	}
 	/*
-	 * We used up one time slice.
-	 */
-	if (--ts->ts_slice > 0)
-		return;
-	/*
 	 * We're out of time, force a requeue at userret().
 	 */
 	ts->ts_slice = sched_slice;


and refusal to use options FULL_PREEMPTION
But no one has unsubscribed to my letter, my patch helps or not in the case of Core2Duo...
There is a suspicion that the problems stem from the sections of code associated with the SMP...
Maybe I'm in something wrong, but I want to help in solving this problem ...