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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julian Elischer Sent: Tuesday, March 01, 2005 2:50 PM To: Sarath Kamisetty Cc: freebsd-hackers@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 <[EMAIL PROTECTED]> 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@freebsd.org mailing list >>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>To unsubscribe, send any mail to "[EMAIL PROTECTED]" >>> >>> >>_______________________________________________ >>freebsd-hackers@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>To unsubscribe, send any mail to "[EMAIL PROTECTED]" >> >> >> _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"