Date: Wed, 30 Apr 2008 17:11:30 -0700 From: Julian Elischer <julian@elischer.org> To: "Murty, Ravi" <ravi.murty@intel.com> Cc: freebsd-hackers@freebsd.org Subject: Re: maybe_preempt_in_ksegrp Message-ID: <48190AB2.4010102@elischer.org> In-Reply-To: <AEBCFC23C0E40949B10BA2C224FC61B00717554C@orsmsx416.amr.corp.intel.com> References: <AEBCFC23C0E40949B10BA2C224FC61B007175275@orsmsx416.amr.corp.intel.com> <4818E40F.9070004@elischer.org> <AEBCFC23C0E40949B10BA2C224FC61B0071752E1@orsmsx416.amr.corp.intel.com> <4818F7F8.6020602@elischer.org> <AEBCFC23C0E40949B10BA2C224FC61B00717554C@orsmsx416.amr.corp.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Murty, Ravi wrote: > Sorry I wish I was part of the development effort. I am just coming on > board with FreeBSD work. > > I guess ksegrps were implemented for the purpose of PROCESS_SCOPE > threads and like you said avoiding a process from hogging the CPU. > > If every thread in the system has it's own ksegrp (SYSTEM_SCOPE) I don't > see this call (maybe_preempt_in_ksegrp) ever getting called :). which is why the default was process scope. > > Thanks > ravi > > > -----Original Message----- > From: Julian Elischer [mailto:julian@elischer.org] > Sent: Wednesday, April 30, 2008 3:52 PM > To: Murty, Ravi > Cc: freebsd-hackers@freebsd.org > Subject: Re: maybe_preempt_in_ksegrp > > Murty, Ravi wrote: >> Julian, >> >> Apologies for sticking to 6.x, I checked and looks like this function >> and several others are out in 7.x. It's just that we've been using 6.x >> for a while and continue to look at it. :) >> >> >> Coming back, I was thinking of the problem the other way around. The >> thread gets put on the ksegrp runq, but we don't know if it gets put > at >> the head of the queue. All we know is we either find a slot or not. If >> we do, great sched_add is called which will add it to a CPU runq and >> check if it can preempt some thread on the target CPU. If we can't > find >> a slot, it checks if it can steal (preempt) some other thread (of the >> same ksegrp) from a cpu. Let's consider the UP case to keep this > simple. >> One of the checks is the priority of the newly runnable thread and the >> curthread on the CPU and the fact that they are part of the same > KSEGRP. >> If both pass, I think it should say "run me" since we just established >> that I am higher priority than what's running on the CPU. >> >> Ravi >> > > > Quite possibly.. > where were you when we needed more > man-power on this :-) > > this was part of the attempt to make a 'fair' scheduler > which would not gove a person 10,000 times the cpu just because > he had 10000 threads :-) > > > It was eventually removed as being too complicated, too resource > intensive, and not solving a problem that people were seeing. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48190AB2.4010102>