From owner-freebsd-arch@FreeBSD.ORG Thu Jul 7 06:53:18 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9881065672 for ; Thu, 7 Jul 2011 06:53:18 +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 AACC38FC08 for ; Thu, 7 Jul 2011 06:53:17 +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 JAA13306; Thu, 07 Jul 2011 09:53:15 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QeiSZ-00092A-Ak; Thu, 07 Jul 2011 09:53:15 +0300 Message-ID: <4E1557D8.7040604@FreeBSD.org> Date: Thu, 07 Jul 2011 09:53:12 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110626 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: David Xu References: <4E147611.6060100@FreeBSD.org> <4E150DE5.8000801@freebsd.org> In-Reply-To: <4E150DE5.8000801@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: SCHED_ULE preempt_thresh: PRI_MIN_KERN -> PRI_MIN_IDLE X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 06:53:18 -0000 on 07/07/2011 04:37 David Xu said the following: > On 2011/07/06 22:49, Andriy Gapon wrote: >> >> I do not have sufficient knowledge of SCHED_ULE, so maybe I shouldn't even talk >> about this, but I couldn't help but notice that many (many) users have reported in >> the past heavy interactivity problems with SCHED_ULE under high load, especially >> I/O-related load. >> >> The universal advice has always been to tune preempt_thresh via sysctl >> kern.sched.preempt_thresh=224. I think that David Xu was the first person that I >> saw recommending this. In all cases users have reported significant improvements. >> I must add that I also have the experience and I do use preempt_thresh=224 to >> this day. >> >> Now, I would like to discuss this phenomenon in two veins: >> 1. Why do we see the interactivity problem with the default setting of >> preempt_thresh=PRI_MIN_KERN (provided that PREEMPTION is enabled and >> FULL_PREEMPTION is not)? Could this be a general ULE issue? Or could it be >> because of some particular hogs (like, purely hypothetically speaking, GEOM threads)? >> >> 2. Why don't we change the default (for PREEMPTION and !FULL_PREEMPTION case) to >> preempt_thresh=PRI_MIN_IDLE? Plus sides of this have been reported via anecdotes. >> What down sides could there be? >> >> Unfortunately somehow I just couldn't grasp ULE priorities and preemption, so I'd >> like to ask for help of those who already have understood these things. >> >> Thank you. > > I think people must have found full preemption hurts performance for > some benchmarks, normally batch-like scheduler (FIFO) have best > peformance for server applications. But for desktop, you want to > tune preempt_thresh to higher value, this should reduce interactivity > jitter. Quite possible, but some data/reports wouldn't hurt. Please also note that preempt_thresh=PRI_MIN_IDLE is not exactly FULL_PREEMPTION, which sets preempt_thresh=PRI_MAX_IDLE. -- Andriy Gapon