sched_4BSD

[João Carlos Mendes Luís]

Julian Elischer wrote:
> Sarath Kamisetty wrote:
>> Hi,
>>
>> How does Linux handle this ? Any idea ?
> 
> If you make 1000 threads, you get 1000 slots on the scheduler. (last 
> time I looked..
> Let me know if I'm wrong).
> 
> The guy next to you with 'vi' gets 1 slot..
> who gets more cpu?

     And how is that different from forking 1000 processes and use 
shared memory to communicate?  I'll tell you: the thread option will be 
better for every user in that machine, so let's promote threads.

     IMHO, a thread should have the same privilege as a full processes, 
and it should count as a process for resource limits.

> 
> 
> 
>> Thanks,
>> Sarat
>>
>> On Mon, 28 Feb 2005 00:26:10 -0800, Julian Elischer 
>> <julian at elischer.org> wrote:
>>  
>>
>>> Ashwin Chandra wrote:
>>>   
>>>
>>>> I wanted to get some clarification about the 4BSD scheduler. I am 
>>>> sort of
>>>> confused why there are two forms of scheduling, one done between 
>>>> processes and
>>>> another done between threads in a process. The priority calculations 
>>>> seem to be
>>>> done only with processes and I assume that the global run queue 
>>>> holds processes,
>>>> not threads. Also why is there only 1 run queue for 1 CPU. What 
>>>> happens to
>>>> blocked processes and ready to be runned processes?
>>>>     
>>>
>>> Part of the challenge of adding threads to a system is to make it 
>>> hard for a
>>> threaded process to "flood" the system run queues so that other 
>>> processes
>>> get no cpu time.
>>>
>>> The scheme in the current freeBSD schedulers is a "crude" method, by 
>>> which
>>> only a limitted number of threads per process are allowed to be added to
>>> the system run queue. RUnnable hreads fo r aprocess are kept on a run 
>>> queue for
>>> the process and only the highest N prioriy  hreads are actually put 
>>> on the
>>> system run queue.
>>>
>>> This is by no means the best way, but rather the
>>> easiest way. I am hoping that some PhD candidate somewhere will decide
>>> that thread scheduling is his topic and will figure out a better way
>>> of doing this.
>>>
>>> both run queues hold threads. This is still a place wjere a lot
>>> of work can be done.
>>>
>>> :-)
>>>
>>>
>>>   
>>>
>>>> Ash
>>>> _______________________________________________
>>>> freebsd-hackers at freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>>> To unsubscribe, send any mail to 
>>>> "freebsd-hackers-unsubscribe at freebsd.org"
>>>>     
>>>
>>> _______________________________________________
>>> freebsd-hackers at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to 
>>> "freebsd-hackers-unsubscribe at freebsd.org"
>>>
>>>   
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"