From owner-freebsd-current@FreeBSD.ORG Thu Jan 4 09:40:44 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A821416A407; Thu, 4 Jan 2007 09:40:43 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <459CCBA1.40305@freebsd.org> Date: Thu, 04 Jan 2007 17:40:49 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20061204 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Roberson References: <20070104005625.D1508@10.0.0.1> In-Reply-To: <20070104005625.D1508@10.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 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 09:40:44 -0000 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