From owner-freebsd-current@FreeBSD.ORG Mon Nov 5 09:14:01 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56224916; Mon, 5 Nov 2012 09:14:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4ED6B8FC15; Mon, 5 Nov 2012 09:13:59 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA26846; Mon, 05 Nov 2012 11:13:58 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TVIkn-0004F0-P0; Mon, 05 Nov 2012 11:13:57 +0200 Message-ID: <50978353.7090204@FreeBSD.org> Date: Mon, 05 Nov 2012 11:13:55 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: David Xu , Jeff Roberson Subject: Re: ULE patch, call for testers References: <50972740.7000703@freebsd.org> In-Reply-To: <50972740.7000703@freebsd.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 09:14:01 -0000 on 05/11/2012 04:41 David Xu said the following: > Another problem I remembered is that a thread on runqueue may be starved > because ULE treats a sleeping thread and a thread waiting on runqueue > differently. If a thread has slept for a while, after it is woken up, > its priority is boosted, but for a thread on runqueue, its priority > will never be boosted. In essential, they should be same becase both of > them are waiting for cpu. If I am a thread, I'd like to wait on sleep > queue rather than on runqueue, since in former case, I will get > bonus, while in later case, I'll get nothing. Under heavy load, > there are many runnable threads, this unfair can cause a very low priority > thread on runqueue to be starved. 4BSD seems not suffer from > this problem, because it also decay cpu time of thread on runqueue. > I think ULE needs some anti-starvation code to give thread a shot > if it is waiting on runqueue too long time. I also noticed this issue and I've been playing with the following patch. Two points: o I am not sure if it is ideologically correct o it didn't improve much the behavior of my workloads In any case, here it is: - extend accounted interactive sleep time to a point where a thread runs (as opposed to be added to runq) --- a/sys/kern/sched_ule.c +++ b/sys/kern/sched_ule.c @@ -1898,8 +1899,21 @@ sched_switch(struct thread *td, struct thread *newtd, int flags) SDT_PROBE2(sched, , , off_cpu, td, td->td_proc); lock_profile_release_lock(&TDQ_LOCKPTR(tdq)->lock_object); TDQ_LOCKPTR(tdq)->mtx_lock = (uintptr_t)newtd; +#if 1 + /* + * If we slept for more than a tick update our interactivity and + * priority. + */ + int slptick; + slptick = newtd->td_slptick; + newtd->td_slptick = 0; + if (slptick && slptick != ticks) { + newtd->td_sched->ts_slptime += + (ticks - slptick) << SCHED_TICK_SHIFT; + sched_interact_update(newtd); + } +#endif sched_pctcpu_update(newtd->td_sched, 0); - #ifdef KDTRACE_HOOKS /* * If DTrace has set the active vtime enum to anything @@ -1990,6 +2004,7 @@ sched_wakeup(struct thread *td) THREAD_LOCK_ASSERT(td, MA_OWNED); ts = td->td_sched; td->td_flags &= ~TDF_CANSWAP; +#if 0 /* * If we slept for more than a tick update our interactivity and * priority. @@ -2001,6 +2016,7 @@ sched_wakeup(struct thread *td) sched_interact_update(td); sched_pctcpu_update(ts, 0); } +#endif /* Reset the slice value after we sleep. */ ts->ts_slice = sched_slice; sched_add(td, SRQ_BORING); -- Andriy Gapon