From owner-freebsd-current@FreeBSD.ORG Thu Apr 17 22:27:33 2003 Return-Path: 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 159A137B401 for ; Thu, 17 Apr 2003 22:27:33 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41F5843FA3 for ; Thu, 17 Apr 2003 22:27:32 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h3I5RS728136; Fri, 18 Apr 2003 01:27:28 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Fri, 18 Apr 2003 01:27:28 -0400 (EDT) From: Jeff Roberson To: Julian Elischer In-Reply-To: Message-ID: <20030418012455.P76635-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users Subject: Re: some small patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 18 Apr 2003 05:27:33 -0000 On Thu, 17 Apr 2003, Julian Elischer wrote: > > > On Thu, 17 Apr 2003, Jeff Roberson wrote: > > > > > On Thu, 17 Apr 2003, Julian Elischer wrote: > > > > > > > > > > > On Thu, 17 Apr 2003, Jeff Roberson wrote: > > > > > > > I object to the sched_clock() change. We've discussed this on threads@ > > > > > > Yes and the clock code doesn't need to know about KSEs and it is of > > > ABSOLUTLY NO difference to the sched_clock() function if it derives the > > > thread from the KSE or derives the KSE from the thread. > > > > > > there is no big difference between > > > sched_clock(curthread); > > > and > > > sched_clock(curthread->td_kse) > > > except that one requires kern_clock.c to know about KSEs and one > > > doesn't. > > > > The difference is in the meaning of the function and not the > > functionality. It is an interface that operates on a property of the kse > > and not the thread. > > No it's an interface that tells the scheduler that curthread > (THAT's A THREAD, OK?) received a clock tick. The scheduler can map > that thread to whatever private data structures it needs to, but > CURTHREAD IS A THREAD! It may have some scheduler provate information > associates with it, (e.g. a KSE) but basically the function statclock is > telling the scheduler. > "hey whatever thread is running now just got a clock tick" > > In fact since the thread in question is always curthread > the whole question is stupid.. it could be a void function, > and use 'curthread' to derive both td and kse. > > The KSE is information PRIVATE TO THE SCHEDULER, in fact there may not > even BE one. So why do you want to pass it as an argument.? > > We disagree on this point. No amount of capitalized text is going to change that. I don't object so strongly to this change except that I disagree with the logic behind it. We need a centralized place to place run queue and slice information. We already have that abstraction. Changing that conflicts with work that I have planned.