From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 9 16:34:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10277106566B for ; Mon, 9 Apr 2012 16:34:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DAFCD8FC1B for ; Mon, 9 Apr 2012 16:34:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 35F3DB9BB; Mon, 9 Apr 2012 12:34:50 -0400 (EDT) From: John Baldwin To: Sushanth Rai Date: Mon, 9 Apr 2012 12:17:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <1333674504.97862.YahooMailClassic@web180016.mail.gq1.yahoo.com> In-Reply-To: <1333674504.97862.YahooMailClassic@web180016.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204091217.05561.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 12:34:50 -0400 (EDT) Cc: freebsd-hackers@freebsd.org Subject: Re: Startvation of realtime piority threads X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:34:51 -0000 On Thursday, April 05, 2012 9:08:24 pm Sushanth Rai wrote: > I understand the downside of badly written realtime app. In my case application runs in userspace without making much syscalls and by all means it is a well behaved application. Yes, I can wire memory, change the application to use mutex instead of spinlock and those changes should help but they are still working around the problem. I still believe kernel should not lower the realtime priority when blocking on resources. This can lead to priority inversion, especially since these threads run at fixed priorities and kernel doesn't muck with them. > > As you suggested _sleep() should not adjust the priorities for realtime threads. Hmm, sched_sleep() for both SCHED_4BSD and SCHED_ULE already does the right thing here in HEAD. if (PRI_BASE(td->td_pri_class) != PRI_TIMESHARE) return; Which OS version did you see this on? -- John Baldwin