maybe_preempt_in_ksegrp

Julian Elischer julian at elischer.org
Wed Apr 30 22:51:35 UTC 2008


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.





More information about the freebsd-hackers mailing list