From owner-freebsd-arch@FreeBSD.ORG Fri Dec 17 14:44:29 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84ADE106564A; Fri, 17 Dec 2010 14:44:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5534F8FC0C; Fri, 17 Dec 2010 14:44:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9566F46B45; Fri, 17 Dec 2010 09:44:28 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B30418A009; Fri, 17 Dec 2010 09:44:27 -0500 (EST) From: John Baldwin To: David Xu Date: Fri, 17 Dec 2010 09:44:27 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201012101050.45214.jhb@freebsd.org> <201012170752.06540.jhb@freebsd.org> <4D0B6E54.2070802@freebsd.org> In-Reply-To: <4D0B6E54.2070802@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012170944.27250.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 17 Dec 2010 09:44:27 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: arch@freebsd.org, Sergey Babkin Subject: Re: Realtime thread priorities 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: Fri, 17 Dec 2010 14:44:29 -0000 On Friday, December 17, 2010 9:06:12 am David Xu wrote: > John Baldwin wrote: > > Yes, we do not do priority lending for sleep locks, and to date we never > > have. This is not a new problem and moving RT priority higher is not > > introducing any _new_ problems. However, it does bring _new_ functionality > > that some people need. Just because you don't need it doesn't mean it isn't > > important. > > > > Don't let the perfect be the enemy of the good. > > > > > I guess that your real requirement is preempting at user boundary > for static priority thread, however current code does not. I doubt that > preempting in kernel path which holding an unknown lock has any > visible benefit for your application. Yes, perfect is not the enemy but > the goal, isn't mutex with priority propagating for perfect ? Actually, in my case what I need is for some other process that holds a lock in the kernel that I need to run as soon as possible. I would be fine with preempting a different thread in the kernel so the thread holding the lock I need can run. It is true that in my case I don't really care about the priority of my thread since it runs on a dedicated CPU. What I really care about is the priority it lends to other threads. I need that to be higher than just about everything else. In my case I could even benefit from priority_propagation() sending an IPI to a remote CPU so the thread I just lent priority to can run, but that is somewhat unique due to my use of cpusets. Without a restricted cpuset you wouldn't need that since the running thread is about to block and will run the lock holder as the next thread if needed. -- John Baldwin