Re: Increase the degree of interactivity ULE scheduler

From: Jeff Roberson <jroberson_at_jroberson.net>
Date: Thu, 3 Nov 2011 10:21:48 -1000 (HST)
On Sat, 22 Oct 2011, Ivan Klymenko wrote:

> Hello people!
>
> I have:
> CPU: Intel(R) Core(TM)2 Duo CPU     T7250  _at_ 2.00GHz (1994.48-MHz K8-class CPU)
> FreeBSD 10.0-CURRENT r226607 amd64
>
> For example during the building of the port lang/gcc46 in four streams (-j 4) with a heavy load on the processor - use the system was nearly impossible - responsiveness was terrible - the mouse cursor sometimes froze on the spot a few seconds...

Am I right in understanding that you have only two cores?  What else is 
running that achieves poor interactivity?  What is the cpu utilization of 
your x server at this time?

>
> I managed to achieve a significant increase in the degree of interactivity ULE scheduler due to the following changes:

This patch probably breaks nice, adaptive idling, and slows the 
interactivity computation.  That being said I'm not sure why it helps you.

It seems that there are increasing reports of bad interactivity creeping 
in to ULE over the last year.  If people can help provide me with data I 
can look into this more.

Thanks for your report.

Jeff


> ##########################
> --- sched_ule.c.orig	2011-10-22 11:40:30.000000000 +0300
> +++ sched_ule.c	2011-10-22 12:25:05.000000000 +0300
> _at__at_ -2119,6 +2119,14 _at__at_
>
> 	THREAD_LOCK_ASSERT(td, MA_OWNED);
> 	tdq = TDQ_SELF();
> +	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;
> #ifdef SMP
> 	/*
> 	 * We run the long term load balancer infrequently on the first cpu.
> _at__at_ -2144,9 +2152,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 +2162,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;
> ##########################
>
> What do you think about this?
>
> Thanks!
Received on Thu Nov 03 2011 - 19:28:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC