From owner-freebsd-current@FreeBSD.ORG Thu Nov 24 00:41:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0CD116A41F; Thu, 24 Nov 2005 00:41:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F405A43D55; Thu, 24 Nov 2005 00:41:20 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAO0fJQf039908; Wed, 23 Nov 2005 17:41:19 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43850C30.4060801@samsco.org> Date: Wed, 23 Nov 2005 17:41:20 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <20051123201837.GA4822@xor.obsecurity.org> <438500BE.3020507@freebsd.org> <20051124000824.GA11032@xor.obsecurity.org> <43850AB7.4000109@freebsd.org> In-Reply-To: <43850AB7.4000109@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: current@freebsd.org, Kris Kennaway Subject: Re: 4BSD process starvation during I/O X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 24 Nov 2005 00:41:23 -0000 David Xu wrote: > Kris Kennaway wrote: > >> On Thu, Nov 24, 2005 at 07:52:30AM +0800, David Xu wrote: >> >> >>> Kris Kennaway wrote: >>> >>> >>> >>>> Perhaps this can be tweaked. >>>> >>>> Kris >>>> >>>> P.S. Please, no responses about how maybe someone could write a new >>>> scheduler that doesn't have this property. >>>> >>>> >>>> >>>> >>>> >>> >>> Can you try it again with FULL_PREEMPTION is turned on ? >>> >> >> >> Didn't really make a difference: >> >> >> > This might only can be fixed when msleep no longer explicitly fiddles > thread priority, let scheduler fully control it. > I don't agree. The more likely problem according Stephan is that threads returning from userland get their priority elevated so they have a better chance of running right away. If you have plans to change how tsleep and msleep manage priorities, please discuss it on arch@ before you start making changes. Scott