From owner-freebsd-current@FreeBSD.ORG Mon Nov 5 02:40:59 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 E4E70F61 for ; Mon, 5 Nov 2012 02:40:59 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B09BC8FC0A; Mon, 5 Nov 2012 02:40:59 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qA52ewj7056993; Mon, 5 Nov 2012 02:40:59 GMT (envelope-from davidxu@freebsd.org) Message-ID: <50972740.7000703@freebsd.org> Date: Mon, 05 Nov 2012 10:41:04 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120822 Thunderbird/14.0 MIME-Version: 1.0 To: Jeff Roberson Subject: Re: ULE patch, call for testers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 02:41:00 -0000 On 2012/11/03 02:26, Jeff Roberson wrote: > I have a small patch to the ULE scheduler that makes a fairly large > change to the way timeshare threads are handled. > > http://people.freebsd.org/~jeff/schedslice.diff > > Previously ULE used a fixed slice size for all timeshare threads. Now > it scales the slice size down based on load. This should reduce latency > for timeshare threads as load increases. It is important to note that > this does not impact interactive threads. But when a thread transitions > to interactive from timeshare it should see some improvement. This > happens when something like Xorg chews up a lot of CPU. > > If anyone has perf tests they'd like to run please report back. I have > done a handful of validation. > > Thanks, > Jeff 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. Regards, David Xu