From owner-freebsd-stable@FreeBSD.ORG  Tue Dec 13 08:40:54 2011
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 60E04106564A;
	Tue, 13 Dec 2011 08:40:54 +0000 (UTC) (envelope-from fidaj@ukr.net)
Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121])
	by mx1.freebsd.org (Postfix) with ESMTP id 0F9278FC08;
	Tue, 13 Dec 2011 08:40:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net;
	s=fsm; 
	h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date;
	bh=02qllFexF+QvnW1q5ymUZZxjyYi7Er87q5EPTv3rxFA=; 
	b=kRx4fPERvEuj3vMPAbWT5xSfgRyH2ufNdtJmGOjw62bi+Al4rw6lEJxT0y8LkWCq0Rzzk4AH93ZQ2c609v2pQ3bg9iFtYEZ/9k2GKJOhJIkY4iz6XeLHmyFIZ2fuPILkBi2udCx4NZfLQedqEtdLvWNpaDxsm73tgGZCCH0wei4=;
Received: from [178.137.138.140] (helo=nonamehost.)
	by fsm2.ukr.net with esmtpsa ID 1RaNut-000G89-UB
	; Tue, 13 Dec 2011 10:40:52 +0200
Date: Tue, 13 Dec 2011 10:40:48 +0200
From: Ivan Klymenko <fidaj@ukr.net>
To: Doug Barton <dougb@FreeBSD.org>
Message-ID: <20111213104048.40f3e3de@nonamehost.>
In-Reply-To: <4EE69C5A.3090005@FreeBSD.org>
References: <4EE1EAFE.3070408@m5p.com> <4EE22421.9060707@gmail.com>
	<4EE6060D.5060201@mail.zedat.fu-berlin.de>
	<4EE69C5A.3090005@FreeBSD.org>
X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd10.0)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de>,
	Current FreeBSD <freebsd-current@freebsd.org>,
	freebsd-stable@freebsd.org, freebsd-performance@freebsd.org
Subject: Re: SCHED_ULE should not be the default
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2011 08:40:54 -0000

> 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
@@ -794,7 +794,8 @@
 	 * 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();
@@ -2118,13 +2119,21 @@
 	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
@@ -2144,9 +2153,6 @@
 		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
@@ -2157,11 +2163,6 @@
 		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 ...