sched_4BSD

[Julian Elischer]

João Carlos Mendes Luís wrote:

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


It's not different, but in that schenario there is no way the programmer 
can AVOID being nasty.
with process scope threads as mentioned before the process itself is 
limitted so that iti doesn't unfairly
peanalise other users for not using 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"
>
> _______________________________________________
> 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"