Date: Tue, 01 Mar 2005 18:15:13 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= <jonny@jonny.eng.br> To: Julian Elischer <julian@elischer.org> Cc: Ashwin Chandra <ashcs@ucla.edu> Subject: Re: sched_4BSD Message-ID: <4224DB61.3060704@jonny.eng.br> In-Reply-To: <4224C74A.2030205@elischer.org> References: <001a01c51d6d$d50ce500$abe243a4@ash> <4222D5A2.9010301@elischer.org> <641e6aa9050301112016d316bb@mail.gmail.com> <4224C74A.2030205@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>>> To unsubscribe, send any mail to
>>>> "freebsd-hackers-unsubscribe@freebsd.org"
>>>>
>>>
>>> _______________________________________________
>>> 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"
>>>
>>>
>
> _______________________________________________
> 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?4224DB61.3060704>