From fdeliege at gmail.com Thu Apr 2 04:16:11 2009 From: fdeliege at gmail.com (=?ISO-8859-1?Q?Fran=E7ois_Deli=E8ge?=) Date: Thu Apr 2 04:16:17 2009 Subject: SPI openmp parallel critical Message-ID: <92c2d900904020345x1541daefy85705fa049b54d8e@mail.gmail.com> Hi list, I am writing a C user defined function that is loading values obtained from an SPI table and that has to perform some operation on each of these values. The values are binary and have a variable size. Since CPU is a bottleneck and since I have multiple cores, I would like the operations to be performed in parallel. Everything goes fine if I define as a critical segment the part where I get the data from tuptable. However, if I remove the critical section I get this error: ERROR: lock 53 is not held I don't always get the error, but it always crashes if I start to have a few values in the SPI table. I would like to eliminate that critical section. Any advice ? I guess someone else already ran in this kind of problem. :-) SPI_connect(); ret = SPI_execute(command, 1, 0); proc = SPI_processed; #pragma omp parallel for shared(proc, SPI_tuptable ) private( mydata, isnull) for (j = 0; j < proc; j++) { // returns datum from the first element #pragma omp critical // would like to eliminate this { mydata = (mydatatype *)PG_DETOAST_DATUM(SPI_getbinval(SPI_tuptable->vals[j], SPI_tuptable->tupdesc, 1, &isnull)); } ... // do something with mydata } SPI_finish(); Cheers, Francois From bugmaster at FreeBSD.org Mon Apr 6 04:07:06 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 6 04:09:23 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200904061107.n36B72tL062031@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/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 37 problems total. From rrs at lakerest.net Wed Apr 8 11:08:22 2009 From: rrs at lakerest.net (Randall Stewart) Date: Wed Apr 8 11:08:28 2009 Subject: A mutex for inter-process ;-) In-Reply-To: References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> Message-ID: Daniel: Ok due to working on a sun benchmark (libMicro) I have came back to this again :-) Turns our our friends at sun in their benchmark arrange for threads in separate process, all started by the same parent process, to collaborate by using pthread_mutex and pthread_cond variables. These are allocated in the main process and mmap()'d into shared memory. Of course none of this works at all in FreeBSD. The reason being that both the pthread_mutex_init and pthread_cond_init under the covers allocate memory for the real pthread_mutex or pthread_cond structure.. not the pointer the user hangs on to. So sun's benchmarks all hang if multiple process are involved since they all go to wait on a local condition variable ;-) I suppose in Sun's Solaris the pthread_mutex structure is the entire structure so that when they mmap it they get it all in shm... So, what really needs to be done here is we rework the pthread_cond/mutex to allowed the shared attribute that they are setting (yes they do this) to actually do something. Of course just being aware of the issue does not solve the problem.. since you really need to NOT malloc inside the cond/mutex init code to make this work.. and instead make the "private" structures setup so the user can malloc these. I did notice that the underlying thr_ library allows one to pass in a allocator .. this might be useful except for it does not fit in the posix model. I am not sure how to proceed with this, since it would take some re-work in the thread library... I could do it but I am sure I would not do it the way y'all would like :-) So for now I am going to see about expanding my little toy library that uses umtx to include cond variables and then adapt the sun libMicro to use that so I can move forward with all of their benchmarks that do multi-process stuff :-) R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From deischen at freebsd.org Sun Apr 12 12:23:53 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Sun Apr 12 13:17:23 2009 Subject: A mutex for inter-process ;-) In-Reply-To: References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> Message-ID: On Wed, 8 Apr 2009, Randall Stewart wrote: > Daniel: > > Ok due to working on a sun benchmark (libMicro) I have > came back to this again :-) > > Turns our our friends at sun in their benchmark arrange for > threads in separate process, all started by the same parent > process, to collaborate by using pthread_mutex and pthread_cond > variables. These are allocated in the main process and mmap()'d into > shared memory. Of course none of this works at all in FreeBSD. > > The reason being that both the pthread_mutex_init and pthread_cond_init > under the covers allocate memory for the real pthread_mutex or pthread_cond > structure.. not the pointer the user hangs on to. So sun's benchmarks > all hang if multiple process are involved since they all go to wait > on a local condition variable ;-) > > I suppose in Sun's Solaris the pthread_mutex structure is the entire > structure so that when they mmap it they get it all in shm... > > So, what really needs to be done here is we rework the > pthread_cond/mutex to allowed the shared attribute that they are > setting (yes they do this) to actually do something. Of course just > being aware of the issue does not solve the problem.. since you really > need to NOT malloc inside the cond/mutex init code to make this work.. and > instead make the "private" structures setup so the user can malloc these. Please see my original reply to this: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=12714+0+archive/2009/freebsd-threads/20090405.freebsd-threads "... and to change our current mutex (and cv) types to be structs instead of pointers." -- DE From bugmaster at FreeBSD.org Mon Apr 13 04:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 13 04:35:11 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200904131107.n3DB72vj085110@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/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 37 problems total. From vsevolodlvovich at xx0007xx.com Mon Apr 13 20:03:24 2009 From: vsevolodlvovich at xx0007xx.com (88.Dorothee) Date: Mon Apr 13 20:37:19 2009 Subject: =?windows-1251?b?0ujv7uL75SDi7ufw4Obl7ej/IOgg7eDo4e7r5eUg/fT0?= =?windows-1251?b?5ery6OLt++Ug7vLi5fL7Lg==?= Message-ID: <3756968409.20090414070250@xx0007xx.com>

Mac?epc??o ?e?e?o???x ?epe?o?opo?.

16 a?pe??.
?. ????, ?????. ????????, 4

??????????, ?????????? ?? ?????????? ?????????? ? ?????????????? ? ??????????? ?????????, ???????? ???????????? ???????? ????????? ?????, ?? ?????. ???????? ?????? ? ??? ?????????? ??????? ??????? ??????? ? ???????????? ? ????? ????: ?? ?? ????????????????? ?????????? ?? ?????? ??????? ?? ?????? ?????? ??????? ? ?????, ?? ? ???? ?????????? ?????.

 ??????? ?????????: ????????? ?? ???????? ?? ????????, ????????? ????????????? ????????, ????????? ?????????? ?????? ?????????? ????????????, ????????? ?????? ??????????, ?????????.

 ????: ??????? ?????????? ?????????? ???????? ? ????????? ? ?????????? ???? ?????? ????? ??????? ?????? ? ????????? ????????, ????????????????? ??????, ??????????? ??? ??????????? ?????????? ????????????.

 ?????????? ?????????:

1. ??????? ? ???????
? ??????????? ?????????????? ? ??????? ??? ???????????? ??????? ?????????? ???????????
? ?????? ???????? ? ???????????????? ?????? ??????????? ?? ?????????? ?????????????
? ??????? ??????????? ??????????? ?????? ? ??????????? ???????????
? ????????? ??????????????? ??????? ? ?????????? ???????????

2. ??????????? ??????????
? ?????????? ?????????? ??????? ? ?????????? ????????????
? ?????????? ? ???????????? ???????? ???????? ?????????? ?? ????????
? ?????? ?????????? ????????? ?? ????????
? ???????????????? ??????? ?? ?????? ? ????. ???????: ???????????? ??????
? ??????????? ???????????? ???????? ? ???????????? ????????????? ????????? ? ?????????? ???????. ??????????? ?????????.
? ????????? ??????? ?? ???????? ? ??????????? ?? ???????????????? ???? ? ??????? ???????

3. ??????????
? ??????????? ? ?????????????? ???????? ??????????
? ??????????? ????? ????????? ????? ?????????? ?????????
? ?????? ????? ? ?????????????? ?????????? ?????????? ???????????
? ????????? ????? ??????????
? ???????? ????????????? ???????? ?????????? ???????????
? ???????????? ???????????????? ??????? ?? ????? ? ???????????

4. ????? ? ????
? ????????? ?????? ? ?????????? ???????: ?????????, ???, ???????? ??????, ????????????
? ??????? ?? ????????? ??????????? ? ??????? ??????
? ????????? ???????? ???????? ?????? ??.?.?.?
? ???? ? ????? ??????? ???? ? ?????????? ???????

5. ????????? ? ??????
? ???????? ???????? ?????????? ??????? ????????. ?????? ????????? ???????
? ???????????? ??????????? ??????? ???????????. ??????? ?12 ???????
? ???????? ??????????? ? ????????? ???????? ???????????
? ??????? ???????? ??? ?????????? ? ???????????? ????????????
? ???????? ???????? ? ???????? ????? ? ?????????? ???????
? ???????? ?????????? ??????????? ??????????? ?? ????????
? ??????? ?????????? ??????? ??????? ?? ????????
? ???????????? ??????????? ???????????????. ??????? ??????????? ??? ????????
? ?????????? ??????????? ?????????

6. ?????? ? ????????????
? ????????????? ? ???????? ????????? ??????????. ???????? ????????????, ????????????, ?????????????
? ??????? ?????????????? ? ????????????? ??????????
? ??????? ??????????? ????????????? ???????
? ??????? ????????? ??????? ? ???????????

7. ??????? ?????????? ?????? ? ?????????? ??????????
? ?????? ????????? ???????? ? ???????????? ???????? (????????, ?????????, ?????????? ??????, ???????????, ????????, ??????????????, ????????, ????????? ????????????? ? ??.)
? ?????????????. ??????? ???????? ??????????????? ???????? ? ???????? ?????????????? ?????????????????

 ? ??????????:
  ? ?????????? ??????????? ????? ?????????? ??????????;
  ? ?????????? ??????????? ???????????? ????? ??????????? ???????;
  ? ?????? ??????????? ???????? ? ???????????? ?????? ??????, ?????, ?????????? ? ???????????? ???????????;
  ? ?????? ???????? ???????????????? ????? ?????? ?? ???? ?????????? ??????? ??????? ? ???????.

?????? ??????: ????????????? ??????????, ?????????????? ?????, ?????? ? ????-???????, ?????????????? ??????????, ?????? ?? ??????? ??????????.

 ???????:
?????????? ????????? ???????????? - ???????????????? ?? ????????? ? ????????? ??????????????? ? ????? ??????-????????????: ??????????, ???????, ??????????. ????? ??????????? ? ??????????????? ???????????. ?????? ????????????? ?????? ? ?????-??????????????? ???????????????? (???) ? ??????? ????????????: ????? ????? ??????? (???), ?????? ????? (??????), ?. ?????????, ?. ??????????, ?. ?????, ?. ????? (??????):

CTO?MOCT? ??AC??? O?HO?O C???ATE??:

? 700.00 ???. ?? ?????? ?????????.

? ??? ??????? ? ???????? ????????? ?????? ?
  5% ? 7% ??????????????.

? ? ????????? ????????:
  ?????????????-???????????????? ????????????,
  ???????????? ??????? ??????????, ???????,
  ?????, ????-?????, ???? ? ?????????.

??????????:

? 9.30-18.00
? ??????? 13.30-14.30
? ??????????? ? 9.00 ? ????.

???????? ??? ???????!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

sluchynie stroki:?? ?? ???????. ??? ????? ??? ??????? dj_elvis@mail.ru?????? ???, ?ankor@sky.ru . ?aleck.heaselgrave@charmed.pp.ru ??? 23527@pechkin.iptelecom.net.ua

From linimon at FreeBSD.org Tue Apr 14 14:37:51 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Apr 14 15:17:55 2009 Subject: threads/133734: 32 bit libthr failing pthread_create() Message-ID: <200904142137.n3ELbnoF025109@freefall.freebsd.org> Synopsis: 32 bit libthr failing pthread_create() Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 14 21:37:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133734 From linimon at FreeBSD.org Tue Apr 14 14:38:43 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Apr 14 15:18:27 2009 Subject: threads/133735: Multi-threaded 32 bit cores can't be used on 64 bit systems Message-ID: <200904142138.n3ELcgB2025158@freefall.freebsd.org> Synopsis: Multi-threaded 32 bit cores can't be used on 64 bit systems Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 14 21:38:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133735 From davidxu at freebsd.org Tue Apr 14 18:30:05 2009 From: davidxu at freebsd.org (David Xu) Date: Tue Apr 14 19:12:58 2009 Subject: threads/133734: 32 bit libthr failing pthread_create() Message-ID: <200904150130.n3F1U4sA031913@freefall.freebsd.org> The following reply was made to PR threads/133734; it has been noted by GNATS. From: David Xu To: bug-followup@freebsd.org, ssanders@opnet.com Cc: Subject: Re: threads/133734: 32 bit libthr failing pthread_create() Date: Wed, 15 Apr 2009 09:27:36 +0800 libkse does not have 32 bit compatible shim on 64 bit platform, you should use libmap.conf and map libkse to libthr. Regards, David Xu From emaste at FreeBSD.org Tue Apr 14 20:17:13 2009 From: emaste at FreeBSD.org (emaste@FreeBSD.org) Date: Tue Apr 14 20:37:46 2009 Subject: threads/133735: Multi-threaded 32 bit cores can't be used on 64 bit systems Message-ID: <200904150317.n3F3HBLk079775@freefall.freebsd.org> Synopsis: Multi-threaded 32 bit cores can't be used on 64 bit systems State-Changed-From-To: open->patched State-Changed-By: emaste State-Changed-When: Wed Apr 15 03:14:25 UTC 2009 State-Changed-Why: This should be fixed in HEAD now (by marcel's changes). There are plans to MFC to 6 & 7. Responsible-Changed-From-To: freebsd-threads->emaste Responsible-Changed-By: emaste Responsible-Changed-When: Wed Apr 15 03:14:25 UTC 2009 Responsible-Changed-Why: Grab to keep track of this. http://www.freebsd.org/cgi/query-pr.cgi?pr=133735 From ssanders at opnet.com Wed Apr 15 07:04:24 2009 From: ssanders at opnet.com (Stephen Sanders) Date: Wed Apr 15 07:42:58 2009 Subject: threads/133735: Multi-threaded 32 bit cores can't be used on 64 bit systems In-Reply-To: <200904150317.n3F3HBLk079775@freefall.freebsd.org> References: <200904150317.n3F3HBLk079775@freefall.freebsd.org> Message-ID: <49E5E5D4.1090600@opnet.com> Is there a specific patch for this? I'd like to back port it to the 6.3 that we're using here. Thanks emaste@FreeBSD.org wrote: > Synopsis: Multi-threaded 32 bit cores can't be used on 64 bit systems > > State-Changed-From-To: open->patched > State-Changed-By: emaste > State-Changed-When: Wed Apr 15 03:14:25 UTC 2009 > State-Changed-Why: > This should be fixed in HEAD now (by marcel's changes). There are plans > to MFC to 6 & 7. > > > Responsible-Changed-From-To: freebsd-threads->emaste > Responsible-Changed-By: emaste > Responsible-Changed-When: Wed Apr 15 03:14:25 UTC 2009 > Responsible-Changed-Why: > Grab to keep track of this. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133735 > > > From ssanders at opnet.com Wed Apr 15 08:40:05 2009 From: ssanders at opnet.com (Stephen Sanders) Date: Wed Apr 15 09:17:15 2009 Subject: threads/133734: 32 bit libthr failing pthread_create() Message-ID: <200904151540.n3FFe4Bw015872@freefall.freebsd.org> The following reply was made to PR threads/133734; it has been noted by GNATS. From: Stephen Sanders To: David Xu Cc: bug-followup@freebsd.org Subject: Re: threads/133734: 32 bit libthr failing pthread_create() Date: Wed, 15 Apr 2009 11:34:54 -0400 This is a multi-part message in MIME format. --------------060604070307050603030809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Retesting by linking with libthr.so on the 6.3/32 bit system worked. Thanks. David Xu wrote: > libkse does not have 32 bit compatible shim on 64 bit platform, > you should use libmap.conf and map libkse to libthr. > > Regards, > David Xu > > --------------060604070307050603030809 Content-Type: text/x-vcard; charset=utf-8; name="ssanders.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ssanders.vcf" begin:vcard fn:Stephen Sanders n:Sanders;Stephen org:OPNET;Coretech adr;dom:;;7255 Woodmont;Bethesda;MD;20814 email;internet:ssanders@opnet.com title:Senior Software Engineer tel;work:240.497.3000 x 2237 x-mozilla-html:TRUE url:http://www.opnet.com version:2.1 end:vcard --------------060604070307050603030809-- From bugmaster at FreeBSD.org Mon Apr 20 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 20 11:09:19 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200904201107.n3KB707u033179@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/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running 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 ryan at rbftpnetworks.com Fri Apr 24 22:57:01 2009 From: ryan at rbftpnetworks.com (ryan@rbftpnetworks.com) Date: Fri Apr 24 22:57:16 2009 Subject: Gaming news link Message-ID: Dear Sir / Madam, We are interested in posting our gaming news and information site on your links section. Our site is GamerBeef.com and can be found at http://www.gamerbeef.com Our site includes daily updated gaming news from all genres and consoles, with focus on PC gaming. We also have a new discussion forum, cheats and screenshots section. We would of course offer a link back to your site in return. Let me know your thoughts. Best Regards, Ryan -- Ryan Barclay Managing Director RBFTP Networks Limited. DDI: +44 (0)870 490 1870 WWW: http://www.rbftpnetworks.com RBFTP Networks Limited Registered in England No 05718807 Registered Office: 68 Aldersbrook Road, London, E12 5DL. From kuan.joe at gmail.com Fri Apr 24 23:08:41 2009 From: kuan.joe at gmail.com (Joseph Kuan) Date: Fri Apr 24 23:08:54 2009 Subject: FreeBSD 7.1 taskq em performance Message-ID: <40bb871a0904241542o3f4d6c6ap62ff71876074bbea@mail.gmail.com> Hi all, I have been hitting some barrier with FreeBSD 7.1 network performance. I have written an application which contains two kernel threads that takes mbufs directly from a network interface and forwards to another network interface. This idea is to simulate different network environment. I have been using FreeBSD 6.4 amd64 and tested with an Ixia box (specialised hardware firing very high packet rate). The PC was a Core2 2.6 GHz with dual ports Intel PCIE Gigabit network card. It can manage up to 1.2 million pps. I have a higher spec PC with FreeBSD 7.1 amd64 and Quadcore 2.3 GHz and PCIE Gigabit network card. The performance can only achieve up to 600k pps. I notice the 'taskq em0' and 'taskq em1' is solid 100% CPU but it is not in FreeBSD 6.4. Any advice? Many thanks in advance Joe From raykinsella78 at gmail.com Mon Apr 27 08:43:45 2009 From: raykinsella78 at gmail.com (Ray Kinsella) Date: Mon Apr 27 08:43:51 2009 Subject: FreeBSD 7.1 taskq em performance In-Reply-To: <40bb871a0904241542o3f4d6c6ap62ff71876074bbea@mail.gmail.com> References: <40bb871a0904241542o3f4d6c6ap62ff71876074bbea@mail.gmail.com> Message-ID: <584ec6bb0904270118v37795ee2k24c9262d4c1abd80@mail.gmail.com> Joseph, I would recommend that you start with PMCStat and figure where the bottleneck is, Given that you have a two threads and your CPU is at 100%, my a apriori guess would be a contention for a spinlock, so I might also try to use LOCK_PROFILING to handle on this. Regards Ray Kinsella On Fri, Apr 24, 2009 at 11:42 PM, Joseph Kuan wrote: > Hi all, > I have been hitting some barrier with FreeBSD 7.1 network performance. I > have written an application which contains two kernel threads that takes > mbufs directly from a network interface and forwards to another network > interface. This idea is to simulate different network environment. > > I have been using FreeBSD 6.4 amd64 and tested with an Ixia box > (specialised hardware firing very high packet rate). The PC was a Core2 2.6 > GHz with dual ports Intel PCIE Gigabit network card. It can manage up to > 1.2 > million pps. > > I have a higher spec PC with FreeBSD 7.1 amd64 and Quadcore 2.3 GHz and > PCIE Gigabit network card. The performance can only achieve up to 600k pps. > I notice the 'taskq em0' and 'taskq em1' is solid 100% CPU but it is not in > FreeBSD 6.4. > > Any advice? > > Many thanks in advance > > Joe > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to " > freebsd-performance-unsubscribe@freebsd.org" > From bugmaster at FreeBSD.org Mon Apr 27 11:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 27 11:09:31 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200904271107.n3RB73wr002453@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/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running 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 ivoras at freebsd.org Tue Apr 28 10:53:39 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Apr 28 10:53:46 2009 Subject: FreeBSD 7.1 taskq em performance In-Reply-To: <40bb871a0904241542o3f4d6c6ap62ff71876074bbea@mail.gmail.com> References: <40bb871a0904241542o3f4d6c6ap62ff71876074bbea@mail.gmail.com> Message-ID: Joseph Kuan wrote: > Hi all, > I have been hitting some barrier with FreeBSD 7.1 network performance. I > have written an application which contains two kernel threads that takes > mbufs directly from a network interface and forwards to another network > interface. This idea is to simulate different network environment. > > I have been using FreeBSD 6.4 amd64 and tested with an Ixia box > (specialised hardware firing very high packet rate). The PC was a Core2 2.6 > GHz with dual ports Intel PCIE Gigabit network card. It can manage up to 1.2 > million pps. > > I have a higher spec PC with FreeBSD 7.1 amd64 and Quadcore 2.3 GHz and > PCIE Gigabit network card. The performance can only achieve up to 600k pps. > I notice the 'taskq em0' and 'taskq em1' is solid 100% CPU but it is not in > FreeBSD 6.4. Maybe this could help you: http://people.yandex-team.ru/~wawa/ It's a SMP patch to the em driver. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20090428/9bc86312/signature.pgp From ykrapiva at gmail.com Thu Apr 30 09:19:27 2009 From: ykrapiva at gmail.com (Yevgen Krapiva) Date: Thu Apr 30 09:19:33 2009 Subject: How to increase the maximum number of threads per process ? Message-ID: <73923e560904300153t22cef75ay81434eeb5a245b2d@mail.gmail.com> Hi. How to increase the maximum number of threads per process ? sysctl kern.threads.max_threads_per_proc=5000 do the trick but if I specify more than 5000 (10000 for example), the system doesn't let me anyway to create more than ~5000 of threads. This is needed for server application which creates a new thread for incoming request. If the number of threads reaches the OS's limits, it crashes. Thanks.