maybe_preempt_in_ksegrp

[Julian Elischer]

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