From alfred at freebsd.org Fri Jan 2 00:47:25 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Fri Jan 2 00:47:32 2009 Subject: (forw) Re: (forw) Re: Process stuck in STOP state Message-ID: <20090102003215.GB60686@elvis.mu.org> David, Julian, there's a pretty good synopsys by Tor attached here for a deadlock in 7.x. Can anyone comment if it's fixed or if there's a way to fix it? thanks, -Alfred ----- Forwarded message from Tor Egge ----- From: Tor Egge To: alfred@freebsd.org Cc: smp@freebsd.org Subject: Re: (forw) Re: Process stuck in STOP state Date: Thu, 01 Jan 2009 22:15:14 +0000 (UTC) Message-Id: <20090101.221514.41667097.Tor.Egge@cvsup.no.freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Sender: owner-freebsd-smp@freebsd.org > Can someone look at this? This is pretty weird, it seems > that somehow there's some deadlock with vnode locks, but it > doesn't appear to be due a leaked vnode lock as "show lockednods" > doesn't show any vnodes locks. > > The trace should be somewhat easy to figure out but I'm kinda > of stuck.. > > Any ideas how this could happen? I had a brief look at msgbuf.txt contained info about some nfs vnodes locked by pid 27645. It looks like thread suspension is broken for the SINGLE_NO_EXIT case. Threads performing an interruptable sleep are suspended, even while holding other resources (e.g. vnode locks). Threads performing a non-interruptable sleep, waiting for resources held by the suspended threads are not suspended. The thread that started the suspension is not woken up since some of the other threads are not yet suspended. - Tor Egge _______________________________________________ freebsd-smp@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-smp To unsubscribe, send any mail to "freebsd-smp-unsubscribe@freebsd.org" ----- End forwarded message ----- -- - Alfred Perlstein From emaste at freebsd.org Fri Jan 2 20:10:08 2009 From: emaste at freebsd.org (Ed Maste) Date: Fri Jan 2 20:10:14 2009 Subject: threads/129956: Threaded process stuck in "vmopar" state, other in "ufs" later. Message-ID: <200901022010.n02KA7J9047338@freefall.freebsd.org> The following reply was made to PR threads/129956; it has been noted by GNATS. From: Ed Maste To: bug-followup@FreeBSD.org, pluknet@gmail.com Cc: Subject: Re: threads/129956: Threaded process stuck in "vmopar" state, other in "ufs" later. Date: Fri, 2 Jan 2009 15:01:04 -0500 > ino 68191367, on dev aacdu0s1g aacdu implies that you're using Adaptec's vendor driver; can you confirm this and provide the build number of the driver you're using? -Ed From pluknet at gmail.com Sat Jan 3 08:40:03 2009 From: pluknet at gmail.com (pluknet) Date: Sat Jan 3 08:40:09 2009 Subject: threads/129956: Threaded process stuck in "vmopar" state, other in "ufs" later. Message-ID: <200901030840.n038e2oR050808@freefall.freebsd.org> The following reply was made to PR threads/129956; it has been noted by GNATS. From: pluknet To: "Ed Maste" Cc: bug-followup@freebsd.org Subject: Re: threads/129956: Threaded process stuck in "vmopar" state, other in "ufs" later. Date: Sat, 3 Jan 2009 11:30:09 +0300 Ed, I'm going to provide more info about this issue (currently far away from console, xmas vacations..). Yes. It's unmodified vendor aacu driver @ IBM ServeRAID 8k at brand new x3650. From arcconf: -------------------------------------------------------- Controller Version Information -------------------------------------------------------- BIOS : 5.2-0 (15421) Firmware : 5.2-0 (15421) Driver : 2.1-15 (15753) Boot Flash : 5.1-0 (15411) -------------------------------------------------------- -- wbr, pluknet From bugmaster at FreeBSD.org Mon Jan 5 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 5 11:09:28 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200901051107.n05B70fc002948@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/129956 threads Threaded process stuck in "vmopar" state, other in "uf o threa/128922 threads threads hang with xorg running o threa/128180 threads pthread_cond_broadcast(3) lost wakeup o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 39 problems total. From craig at animalhead.com Thu Jan 8 01:10:03 2009 From: craig at animalhead.com (craig@animalhead.com) Date: Thu Jan 8 01:10:10 2009 Subject: ThreadsPerChild in Apache2 vs THR in top using Event MPM Message-ID: <9F36BDB2-36D4-4941-BD05-36D2CC5C77AB@animalhead.com> This is more of an Apache question than a FreeBSD question, but I've received no response from enquiries to the users@httpd list. Perhaps someone receiving from this list will be able to help? Our server is running Apache 2.2.11 with the Event MPM under FreeBSD 6.3, on a site that's largely mod_perl2 driven. ThreadsPerChild is specified as 25 in an include file of httpd.conf. The documentation of the Worker MPM (which is said to have the same configuration characteristics as Event) states that each child process creates threads when it starts, and never changes the number of threads. But the THR column of the 'top' utility shows 11 threads per process. Is 'top' just wrong, or is something constraining how many threads are being created? Might my Internet Hosting Provider have built FreeBSD with some such constraint? How can I get more data? The only way I know to ask Apache about its threads configuration is the Apache2::MPM->query facility. Using this facility for all of the values noted in the Apache2::Const documentation yields: MPMQ_MAX_DAEMON_USED(1) = -1 MPMQ_IS_THREADED(2) = 1 MPMQ_IS_FORKED(3) = 2 MPMQ_HARD_LIMIT_DAEMONS(4) = 16 MPMQ_HARD_LIMIT_THREADS(5) = 64 MPMQ_MAX_THREADS(6) = 25 MPMQ_MIN_SPARE_DAEMONS(7) = 0 MPMQ_MIN_SPARE_THREADS(8) = 25 MPMQ_MAX_SPARE_DAEMONS(9) = 0 MPMQ_MAX_SPARE_THREADS(10) = 150 MPMQ_MAX_REQUESTS_DAEMON(11) = 0 MPMQ_MAX_DAEMONS(12) = 10 MPMQ_MAX_THREADS has the same value as ThreadsPerChild, but its name suggests that this number is a maximum. Does this imply that this number may not be created as a child process starts? Help will be much appreciated, cmac www.animalhead.com From alfred at freebsd.org Thu Jan 8 01:47:27 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Thu Jan 8 01:47:33 2009 Subject: ThreadsPerChild in Apache2 vs THR in top using Event MPM In-Reply-To: <9F36BDB2-36D4-4941-BD05-36D2CC5C77AB@animalhead.com> References: <9F36BDB2-36D4-4941-BD05-36D2CC5C77AB@animalhead.com> Message-ID: <20090108012941.GX60686@elvis.mu.org> I think 6.3 uses "libkse" which is N:M threads library, so top(1) can't know how many user threads there are, just kernel threads. Do this: ldd /path/to/httpd If you see libpthread, you're using "kse" and won't see the exact number of threads. -Alfred * craig@animalhead.com [090107 17:10] wrote: > This is more of an Apache question than a FreeBSD question, but I've > received no response from enquiries to the users@httpd list. Perhaps > someone receiving from this list will be able to help? > > Our server is running Apache 2.2.11 with the Event MPM under FreeBSD > 6.3, on a site that's largely mod_perl2 driven. > > ThreadsPerChild is specified as 25 in an include file of httpd.conf. > > The documentation of the Worker MPM (which is said to have the same > configuration characteristics as Event) states that each child process > creates threads when it starts, and never changes the > number of threads. > > But the THR column of the 'top' utility shows 11 threads per process. > Is 'top' just wrong, or is something constraining how many threads are > being created? Might my Internet Hosting Provider have built FreeBSD > with some such constraint? How can I get more data? > > The only way I know to ask Apache about its threads configuration > is the Apache2::MPM->query facility. Using this facility for all of > the values noted in the Apache2::Const documentation yields: > > MPMQ_MAX_DAEMON_USED(1) = -1 > MPMQ_IS_THREADED(2) = 1 > MPMQ_IS_FORKED(3) = 2 > MPMQ_HARD_LIMIT_DAEMONS(4) = 16 > MPMQ_HARD_LIMIT_THREADS(5) = 64 > MPMQ_MAX_THREADS(6) = 25 > MPMQ_MIN_SPARE_DAEMONS(7) = 0 > MPMQ_MIN_SPARE_THREADS(8) = 25 > MPMQ_MAX_SPARE_DAEMONS(9) = 0 > MPMQ_MAX_SPARE_THREADS(10) = 150 > MPMQ_MAX_REQUESTS_DAEMON(11) = 0 > MPMQ_MAX_DAEMONS(12) = 10 > > MPMQ_MAX_THREADS has the same value as ThreadsPerChild, but > its name suggests that this number is a maximum. Does this imply > that this number may not be created as a child process starts? > > Help will be much appreciated, > cmac > www.animalhead.com > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" -- - Alfred Perlstein From julian at elischer.org Thu Jan 8 02:04:45 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Jan 8 02:04:53 2009 Subject: ThreadsPerChild in Apache2 vs THR in top using Event MPM In-Reply-To: <9F36BDB2-36D4-4941-BD05-36D2CC5C77AB@animalhead.com> References: <9F36BDB2-36D4-4941-BD05-36D2CC5C77AB@animalhead.com> Message-ID: <49655892.1010500@elischer.org> craig@animalhead.com wrote: > This is more of an Apache question than a FreeBSD question, but I've > received no response from enquiries to the users@httpd list. Perhaps > someone receiving from this list will be able to help? > > Our server is running Apache 2.2.11 with the Event MPM under FreeBSD > 6.3, on a site that's largely mod_perl2 driven. It depends on which threading library you are using if you see (in top -H) threads waiting in kserel tehn you are using the M:N library, where not every thread in the process makes a kernel thread until it's needed. if you link with libthr instead (see man libmap) you may see different results. (and performance) libthr is the default in 7.x. > > ThreadsPerChild is specified as 25 in an include file of httpd.conf. > > The documentation of the Worker MPM (which is said to have the same > configuration characteristics as Event) states that each child process > creates threads when it starts, and never changes the > number of threads. > > But the THR column of the 'top' utility shows 11 threads per process. > Is 'top' just wrong, or is something constraining how many threads are > being created? Might my Internet Hosting Provider have built FreeBSD > with some such constraint? How can I get more data? > > The only way I know to ask Apache about its threads configuration > is the Apache2::MPM->query facility. Using this facility for all of > the values noted in the Apache2::Const documentation yields: > > MPMQ_MAX_DAEMON_USED(1) = -1 > MPMQ_IS_THREADED(2) = 1 > MPMQ_IS_FORKED(3) = 2 > MPMQ_HARD_LIMIT_DAEMONS(4) = 16 > MPMQ_HARD_LIMIT_THREADS(5) = 64 > MPMQ_MAX_THREADS(6) = 25 > MPMQ_MIN_SPARE_DAEMONS(7) = 0 > MPMQ_MIN_SPARE_THREADS(8) = 25 > MPMQ_MAX_SPARE_DAEMONS(9) = 0 > MPMQ_MAX_SPARE_THREADS(10) = 150 > MPMQ_MAX_REQUESTS_DAEMON(11) = 0 > MPMQ_MAX_DAEMONS(12) = 10 > > MPMQ_MAX_THREADS has the same value as ThreadsPerChild, but > its name suggests that this number is a maximum. Does this imply > that this number may not be created as a child process starts? > > Help will be much appreciated, > cmac > www.animalhead.com > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" From craig at animalhead.com Thu Jan 8 15:36:08 2009 From: craig at animalhead.com (craig@animalhead.com) Date: Thu Jan 8 15:36:15 2009 Subject: ThreadsPerChild in Apache2 vs THR in top using Event MPM In-Reply-To: <20090108012941.GX60686@elvis.mu.org> References: <9F36BDB2-36D4-4941-BD05-36D2CC5C77AB@animalhead.com> <20090108012941.GX60686@elvis.mu.org> Message-ID: <61799EAA-1065-443D-812B-5EAFE0643229@animalhead.com> Thank you both for replying. Yes they wait in kserel and yes libpthread is shown in the ldd output. Is there anything written anywhere on the M:N mechanism? Particularly something that would tell me 1) whether the number of kernel threads (11) is derived from the number of user threads (25), or if not, what controls it? 2) should I adjust the ThreadsPerChild number from 25 given this environment? Thanks again, cmac www.animalhead.com On Jan 7, 2009, at 5:36 PM, Julian Elischer wrote: > > It depends on which threading library you are using > if you see (in top -H) threads waiting in kserel > tehn you are using the M:N library, where not every thread in the > process makes a kernel thread until it's needed. > if you link with libthr instead (see man libmap) > you may see different results. (and performance) > libthr is the default in 7.x. > On Jan 7, 2009, at 5:29 PM, Alfred Perlstein wrote: > I think 6.3 uses "libkse" which is N:M threads library, so top(1) > can't know how many user threads there are, just kernel threads. > > Do this: > ldd /path/to/httpd > > If you see libpthread, you're using "kse" and won't see the exact > number of threads. > From julian at elischer.org Thu Jan 8 18:40:25 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Jan 8 18:40:32 2009 Subject: ThreadsPerChild in Apache2 vs THR in top using Event MPM In-Reply-To: <61799EAA-1065-443D-812B-5EAFE0643229@animalhead.com> References: <9F36BDB2-36D4-4941-BD05-36D2CC5C77AB@animalhead.com> <20090108012941.GX60686@elvis.mu.org> <61799EAA-1065-443D-812B-5EAFE0643229@animalhead.com> Message-ID: <49664892.40602@elischer.org> craig@animalhead.com wrote: > Thank you both for replying. Yes they wait in kserel > and yes libpthread is shown in the ldd output. > > Is there anything written anywhere on the M:N mechanism? > Particularly something that would tell me > > 1) whether the number of kernel threads (11) is derived > from the number of user threads (25), or if not, what > controls it? The 11 is made up of: the number of threads actually waiting in the kernel for input, plus the extra signal thread plus one that is waiting to be woken up as it has no work plus, depending on a number of factors one or two more. Threads that are waiting in userland for a condition variable will not show up at all as they have no kernel resources allocated. > > 2) should I adjust the ThreadsPerChild number from 25 > given this environment? no > > Thanks again, > cmac > www.animalhead.com > > On Jan 7, 2009, at 5:36 PM, Julian Elischer wrote: >> >> It depends on which threading library you are using >> if you see (in top -H) threads waiting in kserel >> tehn you are using the M:N library, where not every thread in the >> process makes a kernel thread until it's needed. >> if you link with libthr instead (see man libmap) >> you may see different results. (and performance) >> libthr is the default in 7.x. >> > > On Jan 7, 2009, at 5:29 PM, Alfred Perlstein wrote: > >> I think 6.3 uses "libkse" which is N:M threads library, so top(1) >> can't know how many user threads there are, just kernel threads. >> >> Do this: >> ldd /path/to/httpd >> >> If you see libpthread, you're using "kse" and won't see the exact >> number of threads. >> > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Jan 12 03:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 12 03:09:25 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200901121107.n0CB70MY092151@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/129956 threads Threaded process stuck in "vmopar" state, other in "uf o threa/128922 threads threads hang with xorg running o threa/128180 threads pthread_cond_broadcast(3) lost wakeup o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 39 problems total. From emaste at freebsd.org Mon Jan 12 12:49:59 2009 From: emaste at freebsd.org (Ed Maste) Date: Mon Jan 12 12:50:05 2009 Subject: threads/128180: pthread_cond_broadcast(3) lost wakeup In-Reply-To: <20081104190221.GT60438@elvis.mu.org> References: <200811041440.mA4Ee31J084489@freefall.freebsd.org> <20081104154113.GP60438@elvis.mu.org> <20081104180349.GA9527@sandvine.com> <20081104190221.GT60438@elvis.mu.org> Message-ID: <20090112203757.GA10620@sandvine.com> On Tue, Nov 04, 2008 at 11:02:21AM -0800, Alfred Perlstein wrote: > * Ed Maste [081104 10:03] wrote: > > On Tue, Nov 04, 2008 at 07:41:13AM -0800, Alfred Perlstein wrote: > > > > > This bug may have been fixed in 6-stable and 6.4. > > > > > > http://svn.freebsd.org/viewvc/base?view=revision&revision=184172 > > > > > > Can you try upgrading? > > > > I tried with the changes from r184172, but I'm still able to reproduce > > the problem using the test app in the PR. With your change it does > > seem to run for on average about 10 times as long before it hangs though. > > Hmm... I'll look into it. Did you have a chance to look into it at all? I didn't really test it very thoroughly, so my my comment about running 10 times as long may not be right -- my main concern is that the test app still does demonstrate the problem with r184172 applied. -Ed From kib at FreeBSD.org Wed Jan 14 09:06:11 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Wed Jan 14 09:06:54 2009 Subject: threads/129956: Threaded process stuck in "vmopar" state, other in "ufs" later. Message-ID: <200901141706.n0EH68UL050821@freefall.freebsd.org> Synopsis: Threaded process stuck in "vmopar" state, other in "ufs" later. State-Changed-From-To: open->analyzed State-Changed-By: kib State-Changed-When: Wed Jan 14 17:05:34 UTC 2009 State-Changed-Why: I have a working patch for the problem. Responsible-Changed-From-To: freebsd-threads->kib Responsible-Changed-By: kib Responsible-Changed-When: Wed Jan 14 17:05:34 UTC 2009 Responsible-Changed-Why: I have a working patch for the problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=129956 From pramod at juniper.net Wed Jan 14 19:16:46 2009 From: pramod at juniper.net (Pramod Srinivasan) Date: Wed Jan 14 19:16:53 2009 Subject: Priority scheduling in 6.x Message-ID: Hi, I have 3 threads low, medium and high , and the scheduling policy is set to SCHED_FIFO. The priority of the threads are at 28,29,30 respectively. Looks like on FreeBSD 6.x, the priority of the threads are not honored while scheduling the threads, but the same test on FreeBSD 7.x seems to work fine. Are there known issues with the priority scheduling in FreeBSD 6.x or am I doing something wrong? (I am using libthr) Any input highly appreciated. Thanks, Pramod From deischen at freebsd.org Wed Jan 14 19:43:18 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Wed Jan 14 19:43:24 2009 Subject: Priority scheduling in 6.x In-Reply-To: References: Message-ID: On Wed, 14 Jan 2009, Pramod Srinivasan wrote: > Hi, > > I have 3 threads low, medium and high , and the scheduling policy is set to > SCHED_FIFO. The priority of the threads are at 28,29,30 respectively. Looks > like on FreeBSD 6.x, the priority of the threads are not honored while > scheduling the threads, but the same test on FreeBSD 7.x seems to work fine. > Are there known issues with the priority scheduling in FreeBSD 6.x or am I > doing something wrong? (I am using libthr) Are you using libpthread or libthr on 6.3? If you are using libthr, then you need to be running with superuser privileges for SCHED_FIFO to work. I'm not sure if this works correctly at all in 6.3. If you are using libpthread, then it will work if the threads are PTHREAD_SCOPE_PROCESS, but will not work if they are PTHREAD_SCOPE_SYSTEM. You do not need superuser privileges for SCHED_FIFO with libpthread and process scope threads. I don't believe the kernel has ever worked properly for libpthread (kse) SCHED_FIFO system scope threads. -- DE From pramod at juniper.net Thu Jan 15 14:21:42 2009 From: pramod at juniper.net (Pramod Srinivasan) Date: Thu Jan 15 14:21:49 2009 Subject: Priority scheduling in 6.x In-Reply-To: Message-ID: Hi Daniel Thanks for your response. On 1/14/09 7:25 PM, "Daniel Eischen" wrote: > On Wed, 14 Jan 2009, Pramod Srinivasan wrote: > >> Hi, >> >> I have 3 threads low, medium and high , and the scheduling policy is set to >> SCHED_FIFO. The priority of the threads are at 28,29,30 respectively. Looks >> like on FreeBSD 6.x, the priority of the threads are not honored while >> scheduling the threads, but the same test on FreeBSD 7.x seems to work fine. >> Are there known issues with the priority scheduling in FreeBSD 6.x or am I >> doing something wrong? (I am using libthr) > > Are you using libpthread or libthr on 6.3? I am using libthr on 6.1, but had similar issues on 6.2 as well. > > If you are using libthr, then you need to be running with > superuser privileges for SCHED_FIFO to work. I'm not sure > if this works correctly at all in 6.3. I am running the program with super user privileges on 6.1, tried this on 6.2 as well. Priority scheduling using libthr does not work, unless I am missing something very basic?. The same program works fine on 7.1, any ideas? > > If you are using libpthread, then it will work if the > threads are PTHREAD_SCOPE_PROCESS, but will not work > if they are PTHREAD_SCOPE_SYSTEM. You do not need > superuser privileges for SCHED_FIFO with libpthread > and process scope threads. I don't believe the kernel > has ever worked properly for libpthread (kse) SCHED_FIFO > system scope threads. I tried libpthread with PTHREAD_SCOPE_PROCESS, it was better, I see that the priority is honored. Thanks for the pointer. Thanks, Pramod From deischen at freebsd.org Thu Jan 15 14:38:47 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Jan 15 14:38:53 2009 Subject: Priority scheduling in 6.x In-Reply-To: References: Message-ID: On Thu, 15 Jan 2009, Pramod Srinivasan wrote: > Hi Daniel > > Thanks for your response. > > On 1/14/09 7:25 PM, "Daniel Eischen" wrote: > >> On Wed, 14 Jan 2009, Pramod Srinivasan wrote: >> >>> Hi, >>> >>> I have 3 threads low, medium and high , and the scheduling policy is set to >>> SCHED_FIFO. The priority of the threads are at 28,29,30 respectively. Looks >>> like on FreeBSD 6.x, the priority of the threads are not honored while >>> scheduling the threads, but the same test on FreeBSD 7.x seems to work fine. >>> Are there known issues with the priority scheduling in FreeBSD 6.x or am I >>> doing something wrong? (I am using libthr) >> >> Are you using libpthread or libthr on 6.3? > > I am using libthr on 6.1, but had similar issues on 6.2 as well. > >> >> If you are using libthr, then you need to be running with >> superuser privileges for SCHED_FIFO to work. I'm not sure >> if this works correctly at all in 6.3. > > I am running the program with super user privileges on 6.1, tried this on > 6.2 as well. Priority scheduling using libthr does not work, unless I am > missing something very basic?. The same program works fine on 7.1, any > ideas? I'm not sure what kernel scheduler you are using (ULE or BSD), but you can try switching it. Other than that, it probably just won't ever work correctly on 6.x. -- DE From pramod at juniper.net Thu Jan 15 15:22:51 2009 From: pramod at juniper.net (Pramod Srinivasan) Date: Thu Jan 15 15:22:57 2009 Subject: Priority scheduling in 6.x In-Reply-To: Message-ID: On 1/15/09 2:38 PM, "Daniel Eischen" wrote: > I'm not sure what kernel scheduler you are using (ULE or BSD), > but you can try switching it. Other than that, it probably > just won't ever work correctly on 6.x. I tried both ULE and BSD, does not work. Do you think that an effort to back port any fixes that may have gone into 7.x too difficult? From deischen at freebsd.org Thu Jan 15 15:27:14 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Jan 15 15:27:20 2009 Subject: Priority scheduling in 6.x In-Reply-To: References: Message-ID: On Thu, 15 Jan 2009, Pramod Srinivasan wrote: > On 1/15/09 2:38 PM, "Daniel Eischen" wrote: > >> I'm not sure what kernel scheduler you are using (ULE or BSD), >> but you can try switching it. Other than that, it probably >> just won't ever work correctly on 6.x. > > I tried both ULE and BSD, does not work. Do you think that an effort to back > port any fixes that may have gone into 7.x too difficult? I don't know - 7.x/8.x have changed significantly from 6.x. 6.x is basically dead, all new work goes into -current and 7.x. -- DE From bugmaster at FreeBSD.org Mon Jan 19 03:07:07 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 19 03:09:16 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200901191107.n0JB7602063126@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/128922 threads threads hang with xorg running o threa/128180 threads pthread_cond_broadcast(3) lost wakeup o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 38 problems total. From bugmaster at FreeBSD.org Mon Jan 26 03:07:08 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 26 03:09:15 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200901261107.n0QB74jF024419@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/128922 threads threads hang with xorg running o threa/128180 threads pthread_cond_broadcast(3) lost wakeup o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 38 problems total.