From owner-freebsd-current@FreeBSD.ORG Thu Jan 4 15:39:32 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9A6516A407; Thu, 4 Jan 2007 15:39:32 +0000 (UTC) (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 6FBD113C44C; Thu, 4 Jan 2007 15:39:32 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id l04FR5hG058233; Thu, 4 Jan 2007 08:27:10 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <459D1CC8.9060604@samsco.org> Date: Thu, 04 Jan 2007 08:27:04 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20061227 SeaMonkey/1.1 MIME-Version: 1.0 To: David Xu References: <20070104005625.D1508@10.0.0.1> <459CCBA1.40305@freebsd.org> In-Reply-To: <459CCBA1.40305@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 04 Jan 2007 08:27:10 -0700 (MST) X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Jeff Roberson , current@freebsd.org Subject: Re: ULE 2.0 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, 04 Jan 2007 15:39:32 -0000 David Xu wrote: > Jeff Roberson wrote: >> Hello everyone, >> >> After a considerable vacation from ULE I have come back to address >> some long standing concerns. I felt that the old double-queue >> mechanism caused very unnatural behavior and have finally come up with >> something I'm happy to replace it with. I've been working on this off >> and on for several months now. Some details are below. More are at: >> http://jeffr-tech.livejournal.com/3729.html >> >> The version now in CVS(1.172) should restore ULE's earlier interactive >> performance under load. I have tested with a make -j128 kernel while >> using mozilla and while playing a dvd. Neither ever skip for me. >> nice now has a more gradual effect than before. It no longer allows >> the total starvation of processes. ULE should also be very slightly >> faster on UP as compared to before. SMP behavior should have changed >> very little although I did simplify some small parts of these >> algorithms. In general, non-interactive tasks are scheduled much more >> intelligently although this may not be apparent under most workloads. >> >> I'm hoping for the following types of feedback from anyone interested >> in testing: >> >> 1) Is the response to nice levels as you would hope? I think nice >> +20 may not inhibit the nice'd thread enough at the moment. >> 2) Is the interactive performance satisfactory? >> 3) Is there any performance degredation for your common tasks? >> 4) Does the cpu estimator give reasonable results? See %cpu in top. >> It is expected that there will be periods where summing up all threads >> will yield slightly over 100% cpu. >> >> Any and all feedback is welcome. Please make sure any problem reports >> are sent to jroberson@chesapeake.net in the to line so I see them more >> quickly. >> >> Thanks, >> Jeff > > I think it might be not a right way to work on FreeBSD thread scheduler, > it is more important to work out a cpu dispatcher rather than inventing > a dynamic priority algorithm to replace 4BSD's algorithm, the 4BSD > dynamic priority algorithm is still the best one I can find, it provides > very good fairness. the most important thing is there should be a > cpu dispatcher which knows how to place a thread on a cpu with cpu > affinity-aware, maybe multiple runqueues, it knows cpu topology, and > may be NUMA awareness, maybe provide cpu partitions, root can create > and destroy a partition, root can add cpu to the partition or remove > a cpu from the parition or move a cpu from partition a to partition b, > bind applications to a partition etcs. On the top of cpu-dispatcher, > there could be 4BSD or other dynamic priority alogrithm, but that's > less important than this one. with this thought, I am going to remove > sched_core as I found the cpu dispatcher is the key thing. > > Regards, > David Xu > It sounds like you want the linux O(1) scheduler. It would be very interesting to see this applied to FreeBSD. Scott