Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 16 Jan 2002 22:37:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 16 Jan 2002 22:37:07 -0500 Received: from [202.135.142.196] ([202.135.142.196]:10507 "EHLO haven.ozlabs.ibm.com") by vger.kernel.org with ESMTP id ; Wed, 16 Jan 2002 22:37:01 -0500 From: Rusty Russell To: mingo@elte.hu Cc: Ingo Molnar , linux-kernel , Linus Torvalds Subject: Re: [PATCH] I3 sched tweaks... In-Reply-To: Your message of "Wed, 16 Jan 2002 23:46:45 BST." Date: Thu, 17 Jan 2002 14:37:09 +1100 Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In message you write: > > On Wed, 16 Jan 2002, Rusty Russell wrote: > > > > > 4) scheduler_tick needs no args (p is always equal to current). > > > > > > i have not taken this part. We have 'current' calculated in > > > update_process_times(), so why not pass it along to the scheduler_tick() > > > function? > > > > Because it's redundant. It's *always* p == current (and the code > > assumes this!), but I had to grep the callers to find out. > > we pass pointers across functions regularly, even if the pointer could be > calculated within the function. We do this in the timer code too. Look at it semantically: scheduler_tick() is just a function called regularly for scheduler maintenance. It might need the CPU number, the runqueue length, or phase of the moon: the caller shouldn't care. If it was a static fn, maybe this optimization makes sense. But it's an interface wart, and the "optimization" is utterly marginal anyway. That said, I never would have sent such a trivial patch by itself: I can't believe how many keystrokes were wasted over this issue! Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/