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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
