maybe_preempt_in_ksegrp

[Murty, Ravi]

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 :).

Thanks
ravi


-----Original Message-----
From: Julian Elischer [mailto:julian at elischer.org] 
Sent: Wednesday, April 30, 2008 3:52 PM
To: Murty, Ravi
Cc: freebsd-hackers at 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.