Date: Fri, 18 Apr 2003 01:27:28 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@freebsd.org> Subject: Re: some small patches Message-ID: <20030418012455.P76635-100000@mail.chesapeake.net> In-Reply-To: <Pine.BSF.4.21.0304172159030.54473-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030418012455.P76635-100000>