Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, 13 Jul 2008, Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Yes, I had not yet upgraded my x.org port when testing this, so it was the same x.org that was fine under 6.3. Also: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. It shows *a* difference, but perhaps not the *same* difference. Please humour me and rule it out. Okay. I am in the process of recompiling all my ports, so after that is done I will boot with a GENERIC kernel and see what happens. After trying this, I can't seem to reproduce the sound skipping behavior, unless I do something fairly extreme like "make -j 6". But the mouse does seem to skip when a compile is running, so I do believe there is a regression. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, Jul 13, 2008 at 12:47 AM, Eugene Grosbein <[EMAIL PROTECTED]> wrote: > On Sun, Jul 13, 2008 at 03:11:23AM +0200, Kris Kennaway wrote: > >> >It seems like there has been a regression in interactivity from >> >6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After >> >upgrading my single-cpu amd64 box, 7.0 has much worse latency. When >> >running a kernel compile, there is a noticeable lag to echo my typing or >> >scroll my browser windows, and playing an mp3 frequently cuts out for a >> >second or two. This did not happen on 6.3-RELEASE. >> >> Are you sure it's not the x.org server bug that was present in the >> version shipped with 7.0? > > No, it's not. I have exactly the same problem with SCHED_4BSD > after upgrade from 6.3-STABLE to 7.0-STABLE. I didn't upgrade > my x.org 6.9.0, only OS (all 6.x compat shims are installed). > There is some sort of regression, certainly. IIRC some folks reported performance degradation using SCHED_4BSD in the past after the SMP fixes, so this isn't a new news story. SCHED_ULE isn't going to be default until 7.1-RELEASE I believe because they might be fanning out a few bugs in -CURRENT (the number of bugs are small from what I've seen) and MFC'ing them to 7-RELEASE. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Yes, I had not yet upgraded my x.org port when testing this, so it was the same x.org that was fine under 6.3. Also: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. It shows *a* difference, but perhaps not the *same* difference. Please humour me and rule it out. Okay. I am in the process of recompiling all my ports, so after that is done I will boot with a GENERIC kernel and see what happens. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, Jul 13, 2008 at 03:11:23AM +0200, Kris Kennaway wrote: > >It seems like there has been a regression in interactivity from > >6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After > >upgrading my single-cpu amd64 box, 7.0 has much worse latency. When > >running a kernel compile, there is a noticeable lag to echo my typing or > >scroll my browser windows, and playing an mp3 frequently cuts out for a > >second or two. This did not happen on 6.3-RELEASE. > > Are you sure it's not the x.org server bug that was present in the > version shipped with 7.0? No, it's not. I have exactly the same problem with SCHED_4BSD after upgrade from 6.3-STABLE to 7.0-STABLE. I didn't upgrade my x.org 6.9.0, only OS (all 6.x compat shims are installed). There is some sort of regression, certainly. Eugene Grosbein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Yes, I had not yet upgraded my x.org port when testing this, so it was the same x.org that was fine under 6.3. Also: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. It shows *a* difference, but perhaps not the *same* difference. Please humour me and rule it out. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, Jul 13, 2008 at 01:34:11AM -0700, Nate Eldredge wrote: > On Sun, 13 Jul 2008, Kris Kennaway wrote: > > > Nate Eldredge wrote: > >> I wrote a small program which forks two processes that run gettimeofday() > >> in a tight loop to see how long they get scheduled out. On 6.3 the > >> maximum > >> latency is usually under 100 ms. On 7.0 it is 500 ms or more even when > >> nothing else is running on the system. When a compile is also running it > >> is sometimes 1400 ms or more. > > This test shows a difference even in single user mode, when X is not > running at all. I was seeing similar problems (audio stutter during compiles, jerky mouse) after upgrading to 7.0. The box is an Athlon-XP 2400+ with 1GB of RAM. Since removing SMP support from the kernel and switching to ULE, interactivity has been acceptible again. I did not update the xserver at the time, and I can't recall if it has been updated since. Stefan pgpwzVr88QUYs.pgp Description: PGP signature
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Yes, I had not yet upgraded my x.org port when testing this, so it was the same x.org that was fine under 6.3. Also: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Kris I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. SCHED_ULE is much better, so I've switched over. But it's not the default yet, and most people are still going to be using SCHED_4BSD. It used to be acceptable but now it isn't. Does anyone know why it's regressed so badly? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
--- Steve Watt <[EMAIL PROTECTED]> wrote: > In > <[EMAIL PROTECTED]>, > >N)? > > "Problem"? Scheduler activations may be used to > build M:N > systems, but that is not a requirement -- you can > easily > build a 1:1 (all threads are system contention > scope) system > with activations. > But the POSIX std allows one to specify that the thread be either process scope or system scope, and if some of them are system/process scope -that leads to an M:N system. > Admittedly, at this point in industry experience, > most > threads experts will say that M:N threading usually > isn't > worth the implementation headaches. But there are Hmm -so no implementation can provide a good M:N system. [snip] > convenience. Very many processes with thousands of > threads > in them will drag down a 1:1 system pretty rapidly. > I get the idea that not everyone in the pthreads-user community is content with a 1:1 model (though I would be). [snip] > handle contention scope correctly. I don't think > anyone > has built such a system, but would be happy to be > proven > wrong -- it'd be a useful advancement of the art. Isn't a system supporting both process/system scope a POSIX requirement? BTW -the std sounds weird to me at times. They want to treat a process as a shell with a single (hypothetical) thread in it -and their scheduling classes don't have a 1:1 correspondence to the unix scheduler. SCHED_RR is a realtime scheduling class but I mistook it for a round robin scheduler:-). > One > challenge is accounting for time on threads that > don't do > much work when awakened before going back to sleep If every kernel thread were to be treated at par with a process, we wouldn't need a special algorithm. regards -kamal Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
In <[EMAIL PROTECTED]>, Kamal R. Prasad <[EMAIL PROTECTED]> wrote: >--- Steve Watt <[EMAIL PROTECTED]> wrote: [ snip ] >> NPTL is a particular (less brain damaged than >> LinuxThreads) >> implementation of the POSIX thread standard. >> >> Likewise, scheduler activations are a decent >> implementation of > >doesn't that have a problem with M:N performance (M |= >N)? "Problem"? Scheduler activations may be used to build M:N systems, but that is not a requirement -- you can easily build a 1:1 (all threads are system contention scope) system with activations. Admittedly, at this point in industry experience, most threads experts will say that M:N threading usually isn't worth the implementation headaches. But there are definite classes of problem, often having to do with certain styles of user-interface design or a less-than-optimal object system, where thousands of threads are a useful developer convenience. Very many processes with thousands of threads in them will drag down a 1:1 system pretty rapidly. >> Julian> so how does that differ from what we have >> ... a >> Julian> native pthreads library? >> >> Kamal>I just said if it was conformant with NPTL, >> thread and >> Kamal>process scheduling would co-exist. >> >> Uh, as far as I understand, in NPTL, each thread >> gets a scheduler >> slot, and it is my understanding that there is >> nothing to protect >> against the issue that Julian is asking about (1000 >> threads of a >> single process *do* get 1000 times the time slices). >> > >(AFAIK) Referring to the POSIX std (and not NPTL) -if >threads were defined within process scope and not >system scope -the scheduling attributes of the process >will apply. Yes, and a system that has both system scope and process scope is usually called an M:N system. I will grant that it is possible for the kernel to be aware of all of the threads in the system (i.e. a 1:1 model) but handle contention scope correctly. I don't think anyone has built such a system, but would be happy to be proven wrong -- it'd be a useful advancement of the art. One challenge is accounting for time on threads that don't do much work when awakened before going back to sleep -- if there are 1000 process-scope threads, and all of them run for half a millisecond and block, in the aggregate you need to charge the process the entire 500mS, or the timesharing characteristics won't come out right. It's somewhat challenging to do that charging cheaply. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
--- Steve Watt <[EMAIL PROTECTED]> wrote: [snip] > > No, POSIX 1003.1 is the standard, the thread portion > was known for > some time as 1003.1c, but was combined in with the > base. > Ok -I meant the POSIX std when I answered Julian. > NPTL is a particular (less brain damaged than > LinuxThreads) > implementation of the POSIX thread standard. > > Likewise, scheduler activations are a decent > implementation of doesn't that have a problem with M:N performance (M |= N)? > threads. I'll refrain from commenting further about > libc_r. > > Julian> so how does that differ from what we have > ... a > Julian> native pthreads library? > > Kamal>I just said if it was conformant with NPTL, > thread and > Kamal>process scheduling would co-exist. > > Uh, as far as I understand, in NPTL, each thread > gets a scheduler > slot, and it is my understanding that there is > nothing to protect > against the issue that Julian is asking about (1000 > threads of a > single process *do* get 1000 times the time slices). > (AFAIK) Referring to the POSIX std (and not NPTL) -if threads were defined within process scope and not system scope -the scheduling attributes of the process will apply. regards -kamal Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
[ Attempted to clean up citations, apologies if I mis-attribute something ] In article <[EMAIL PROTECTED]>, Kamal R. Prasad <[EMAIL PROTECTED]> wrote: Kamal>--- Julian Elischer <[EMAIL PROTECTED]> wrote: Julian> Kamal R. Prasad wrote: Kamal>>--- Julian Elischer <[EMAIL PROTECTED]> wrote: Julian>>Kamal R. Prasad wrote: Kamal>>>Maybe the freebsd implementation should implement Kamal>>>NPTL in entirety. Julian>>NPTL? Julian>>New Pthreads Library from Library? No, Native POSIX Threads Library for Linux. It's a Linux implementation of kernel-level threads that was spearheded by Ulrich Drepper. It fixes most (all?) of the ugly signal problems that LinuxThreads had. Kamal>>Yes. Julian>>isn't that GPL'd? Yes. Kamal>No -it is a standard. The linux implementation of nptl Kamal>is gpl'ed. No, POSIX 1003.1 is the standard, the thread portion was known for some time as 1003.1c, but was combined in with the base. NPTL is a particular (less brain damaged than LinuxThreads) implementation of the POSIX thread standard. Likewise, scheduler activations are a decent implementation of threads. I'll refrain from commenting further about libc_r. Julian> so how does that differ from what we have ... a Julian> native pthreads library? Kamal>I just said if it was conformant with NPTL, thread and Kamal>process scheduling would co-exist. Uh, as far as I understand, in NPTL, each thread gets a scheduler slot, and it is my understanding that there is nothing to protect against the issue that Julian is asking about (1000 threads of a single process *do* get 1000 times the time slices). Whether that is a bug or a feature depends very heavily on the system load. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9" Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
This looks like a linux thing to me... http://en.wikipedia.org/wiki/NPTL If its a spec, i'd like to know how. On Thu, 3 Mar 2005, Julian Elischer wrote: Kamal R. Prasad wrote: --- Julian Elischer <[EMAIL PROTECTED]> wrote: Kamal R. Prasad wrote: --- Lucas Holt <[EMAIL PROTECTED]> wrote: Wouldn't a multi threaded program potentially need more cpu time than vi? No. That is not a given. Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? Threads are meant to take advantage of concurrency. Maybe the freebsd implementation should implement NPTL in entirety. NPTL? New Pthreads Library from Library? Yes. isn't that GPL'd? No -it is a standard. The linux implementation of nptl is gpl'ed. regards -kamal so how does that differ from what we have ... a native pthreads library? = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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]"
Re: sched_4BSD
Kamal R. Prasad wrote: --- Julian Elischer <[EMAIL PROTECTED]> wrote: so how does that differ from what we have ... a native pthreads library? I just said if it was conformant with NPTL, thread and process scheduling would co-exist. in theory it does in FreeBSD's pthreads library. (though it needs work) regards -kamal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
--- Julian Elischer <[EMAIL PROTECTED]> wrote: > > > Kamal R. Prasad wrote: > > >--- Julian Elischer <[EMAIL PROTECTED]> wrote: > > > > > > > >>Kamal R. Prasad wrote: > >> > >> > >> > >>>--- Lucas Holt <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > >>> > >>> > Wouldn't a multi threaded program potentially > need > more cpu time than > vi? > > > > > >>>No. That is not a given. > >>> > >>> > >>> > >>> > >>> > Multithreaded apps are created to do a lot of > computation or > because they have a lot of concurrent activity > > > >>that > >> > >> > might block right? > > > > > > >>>Threads are meant to take advantage of > concurrency. > >>> > >>> > >>>Maybe the freebsd implementation should implement > >>> > >>> > >>NPTL > >> > >> > >>>in entirety. > >>> > >>> > >>> > >>> > >>NPTL? > >>New Pthreads Library from Library? > >> > >> > >Yes. > > > > > >>isn't that GPL'd? > >> > >> > >> > >No -it is a standard. The linux implementation of > nptl > >is gpl'ed. > >regards > >-kamal > > > > > > so how does that differ from what we have ... a > native pthreads library? > I just said if it was conformant with NPTL, thread and process scheduling would co-exist. regards -kamal > > > > > >= > > > >Kamal R. Prasad > >UNIX systems consultant > >[EMAIL PROTECTED] > > > >In theory, there is no difference between theory > and practice. In practice, there is:-). > > > > > >__ > >Do You Yahoo!? > >Tired of spam? Yahoo! Mail has the best spam > protection around > >http://mail.yahoo.com > > > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
Kamal R. Prasad wrote: --- Julian Elischer <[EMAIL PROTECTED]> wrote: Kamal R. Prasad wrote: --- Lucas Holt <[EMAIL PROTECTED]> wrote: Wouldn't a multi threaded program potentially need more cpu time than vi? No. That is not a given. Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? Threads are meant to take advantage of concurrency. Maybe the freebsd implementation should implement NPTL in entirety. NPTL? New Pthreads Library from Library? Yes. isn't that GPL'd? No -it is a standard. The linux implementation of nptl is gpl'ed. regards -kamal so how does that differ from what we have ... a native pthreads library? = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
On Mon, Feb 28, 2005, Julian Elischer 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. I think most of the PhD theses in that area were written over a decade ago. ;-) Carl Waldspurger comes to mind in particular. The UC Berkeley CSUA, which runs a shell box often supporting hundreds of simultaneous users, implemented one of those ideas in FreeBSD 4.X a long time ago. The basic idea, called lottery scheduling, is that each user gets some number of tickets, say 1000. Users use their tickets to ``fund'' their processes, and each process in the system gets a share of the CPU proportional to the number of tickets it has. Their algorithm is randomized, but more sophistocated approaches such as stride scheduling are deterministic. Patches are available at: http://www.csua.berkeley.edu/computing/software/lottery-sched.html One of the nice features of something like this over standard Unix priority scheduling is that problems such as starvation just don't happen. The ticket quota idea is also a nice way to deal with the problem you mention. IIRC, Luigi had a weighted fair queuing scheduler for 4.X as well. This is basically the same idea viewed from a networking person's point of view. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
On March 2, 2005 12:09 pm, Julian Elischer wrote: > NPTL? > New Pthreads Library from Library? > isn't that GPL'd? Native Posix Threads Library All I know about it is the name. :) -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: sched_4BSD
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]"
Re: sched_4BSD
--- Julian Elischer <[EMAIL PROTECTED]> wrote: > > > Kamal R. Prasad wrote: > > >--- Lucas Holt <[EMAIL PROTECTED]> wrote: > > > > > > > >>Wouldn't a multi threaded program potentially need > >>more cpu time than > >>vi? > >> > >> > > > >No. That is not a given. > > > > > > > >>Multithreaded apps are created to do a lot of > >>computation or > >>because they have a lot of concurrent activity > that > >>might block right? > >> > >> > >> > >Threads are meant to take advantage of concurrency. > > >Maybe the freebsd implementation should implement > NPTL > >in entirety. > > > > > NPTL? > New Pthreads Library from Library? Yes. > isn't that GPL'd? > No -it is a standard. The linux implementation of nptl is gpl'ed. regards -kamal = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
Kamal R. Prasad wrote: --- Lucas Holt <[EMAIL PROTECTED]> wrote: Wouldn't a multi threaded program potentially need more cpu time than vi? No. That is not a given. Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? Threads are meant to take advantage of concurrency. Maybe the freebsd implementation should implement NPTL in entirety. NPTL? New Pthreads Library from Library? isn't that GPL'd? On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: If you make 1000 threads, you get 1000 slots on the scheduler. (last time I looked.. Let me know if I'm wrong). depends on whether it is defined to execute in system scope or not. I presume you have looked at it recently then.. I have not looked at the linux scheduler in a while.. how do they stop 100o threads from getting 1000 shots at the scheduler? regards -kamal = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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]"
Re: sched_4BSD
Lucas Holt wrote: Wouldn't a multi threaded program potentially need more cpu time than vi? Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? Isn't that what nice is for? if (only) two processes are using all the cpu they can get, and one is written using 1000 threads, then why should it get 1000/1001 of the cpu? On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: 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? Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory IoM site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
--- Lucas Holt <[EMAIL PROTECTED]> wrote: > Wouldn't a multi threaded program potentially need > more cpu time than > vi? No. That is not a given. > Multithreaded apps are created to do a lot of > computation or > because they have a lot of concurrent activity that > might block right? > Threads are meant to take advantage of concurrency. Maybe the freebsd implementation should implement NPTL in entirety. > > On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: > >> > > > > If you make 1000 threads, you get 1000 slots on > the scheduler. (last > > time I looked.. > > Let me know if I'm wrong). > > depends on whether it is defined to execute in system scope or not. regards -kamal = Kamal R. Prasad UNIX systems consultant [EMAIL PROTECTED] In theory, there is no difference between theory and practice. In practice, there is:-). __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
Wouldn't a multi threaded program potentially need more cpu time than vi? Multithreaded apps are created to do a lot of computation or because they have a lot of concurrent activity that might block right? On Mar 1, 2005, at 2:49 PM, Julian Elischer wrote: 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? Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory IoM site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
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 <[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]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sched_4BSD
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 <[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]"
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]"
Re: sched_4BSD
Hi, How does Linux handle this ? Any idea ? 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]"
Re: sched_4BSD
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]"
