Date: Wed, 2 Mar 2005 10:39:20 -0500 From: "Smith III, Edward Mr. CAA/ISC" <ed.smithiii@us.army.mil> To: <julian@elischer.org>, <sarath.kamisetty@gmail.com> Cc: ashcs@ucla.edu Subject: RE: sched_4BSD Message-ID: <0A907D6523E90246822D32FA2344E244015ECF@CAA-UNCLMAIL.caa.army.mil>
next in thread | raw e-mail | index | archive | help
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...=20 -----Original Message----- From: owner-freebsd-hackers@freebsd.org [mailto:owner-freebsd-hackers@freebsd.org] 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 ? > =20 > 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@elischer.org> wrote: > =20 > >>Ashwin Chandra wrote: >> =20 >> >>>I wanted to get some clarification about the 4BSD scheduler. I am=20 >>>sort of confused why there are two forms of scheduling, one done=20 >>>between processes and another done between threads in a process. The=20 >>>priority calculations seem to be done only with processes and I=20 >>>assume that the global run queue holds processes, not threads. Also=20 >>>why is there only 1 run queue for 1 CPU. What happens to blocked processes and ready to be runned processes? >>> =20 >>> >>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=20 >>processes get no cpu time. >> >>The scheme in the current freeBSD schedulers is a "crude" method, by=20 >>which only a limitted number of threads per process are allowed to be=20 >>added to the system run queue. RUnnable hreads fo r aprocess are kept=20 >>on a run queue for the process and only the highest N prioriy hreads=20 >>are actually put on the system run queue. >> >>This is by no means the best way, but rather the easiest way. I am=20 >>hoping that some PhD candidate somewhere will decide that thread=20 >>scheduling is his topic and will figure out a better way of doing=20 >>this. >> >>both run queues hold threads. This is still a place wjere a lot of=20 >>work can be done. >> >>:-) >> >> >> =20 >> >>>Ash >>>_______________________________________________ >>>freebsd-hackers@freebsd.org mailing list=20 >>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> =20 >>> >>_______________________________________________ >>freebsd-hackers@freebsd.org mailing list=20 >>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> >> =20 >> _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0A907D6523E90246822D32FA2344E244015ECF>