sched_4BSD

[Smith III, Edward Mr. CAA/ISC]

Yes, but you still incur a lot of context switching overhead between the
1000 threads.  Increasing the time quantum should give you better
throughput with a penalty to interactivity which isn't really an issue
if no one is running a graphical desktop.
???
I think... 

-----Original Message-----
From: owner-freebsd-hackers at freebsd.org
[mailto:owner-freebsd-hackers at freebsd.org] On Behalf Of Julian Elischer
Sent: Tuesday, March 01, 2005 2:50 PM
To: Sarath Kamisetty
Cc: freebsd-hackers at freebsd.org; Ashwin Chandra
Subject: Re: sched_4BSD



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?



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