Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 5 Dec 2001 17:02:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 5 Dec 2001 17:00:11 -0500 Received: from e31.co.us.ibm.com ([32.97.110.129]:35260 "EHLO e31.co.us.ibm.com") by vger.kernel.org with ESMTP id ; Wed, 5 Dec 2001 16:59:20 -0500 Date: Wed, 5 Dec 2001 13:58:51 -0800 From: Mike Kravetz To: Ingo Molnar Cc: linux-kernel Subject: Re: Scheduler Cleanup Message-ID: <20011205135851.D1193@w-mikek2.des.beaverton.ibm.com> In-Reply-To: <20011126114610.B1141@w-mikek2.des.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mingo@elte.hu on Wed, Nov 28, 2001 at 02:07:08AM +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 28, 2001 at 02:07:08AM +0100, Ingo Molnar wrote: > > On Mon, 26 Nov 2001, Mike Kravetz wrote: > > > I'm happy to see the cleanup of scheduler code that went into > > 2.4.15/16. One small difference in behavior (I think) is that the > > currently running task is not given preference over other tasks on the > > runqueue with the same 'goodness' value. I would think giving the > > current task preference is a good thing (especially in light of recent > > discussions about too frequent moving/rescheduling of tasks). Can > > someone provide the rational for this change? Was it just the result > > of making the code cleaner? Is it believed that this won't really > > make a difference? > > i've done this change as part of the sched_yield() fixes/cleanups, and the > main reason for it is that the current process is preferred *anyway*, due > to getting the +1 boost via current->mm == this_mm in goodness(). > > (and besides, the percentage/probability of cases where we'd fail reselect > a runnable process where the previous scheduler would reselect it is very > very low. It does not justify adding a branch to the scheduler hotpath > IMO. In 99.9% of the cases if a runnable process is executing schedule() > then there is a higher priority process around that will win the next > selection. Or if there is a wakeup race, then the process will win the > selection very likely because it won the previous selection.) > > Ingo FYI - I have been having a heck of a time getting our MQ scheduler to work well in 2.4.16/2.5.0. The problem was mainly with performance when running (I'm afraid to say) VolanoMark. Turns out that the above change makes a big difference in this benchmark when running with the MQ scheduler. There is an almost 50% drop in performance on my 8 way. I suspect that one would not see such a dramatic drop (if any) with the current scheduler as its performance is mostly limited by lock contention in this benchmark. Now, I'm aware that very few people are actively using our MQ scheduler, and even fewer care about VolanoMark performance (perhaps no one on this list). However, this seemed like an interesting observation. -- Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/