From owner-freebsd-threads@FreeBSD.ORG Sun Mar 11 09:48:37 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 038BC16A401; Sun, 11 Mar 2007 09:48:37 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from postfix2-g20.free.fr (postfix2-g20.free.fr [212.27.60.43]) by mx1.freebsd.org (Postfix) with ESMTP id AB18813C442; Sun, 11 Mar 2007 09:48:36 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix2-g20.free.fr (Postfix) with ESMTP id 25378C09190; Sun, 11 Mar 2007 09:16:37 +0100 (CET) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 117A87D73; Sun, 11 Mar 2007 10:16:19 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 700F49BF12; Sun, 11 Mar 2007 09:16:18 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 3E6004065; Sun, 11 Mar 2007 10:16:18 +0100 (CET) Date: Sun, 11 Mar 2007 10:16:18 +0100 From: Jeremie Le Hen To: Martin Blapp Message-ID: <20070311091617.GG2887@obiwan.tataz.chchile.org> References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <20070310012921.I6787@godot.imp.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070310012921.I6787@godot.imp.ch> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Daniel Eischen , gerald@freebsd.org, Julian Elischer , freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 09:48:37 -0000 Hi Martin, On Sat, Mar 10, 2007 at 01:32:26AM +0100, Martin Blapp wrote: > > Hi, > > >There is no portable way to identify threads in another process. There is > >also no guarantee that the tread is even externally visible. Take > > But is it true for FreeBSD that 'ps -Hauxwww' should show all threads > for a process with libc_r, libpthreads.so, or libthr.so ? May I advice you to read these two posts for a thorough explanation. http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003674.html http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003682.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-threads@FreeBSD.ORG Sun Mar 11 10:13:00 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C36C016A400; Sun, 11 Mar 2007 10:13:00 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.freebsd.org (Postfix) with ESMTP id 4361313C481; Sun, 11 Mar 2007 10:12:59 +0000 (UTC) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id l2BACqbt015083; Sun, 11 Mar 2007 11:12:53 +0100 (CET) (envelope-from mb@imp.ch) Date: Sun, 11 Mar 2007 11:12:52 +0100 (CET) From: Martin Blapp To: Jeremie Le Hen In-Reply-To: <20070311091617.GG2887@obiwan.tataz.chchile.org> Message-ID: <20070311111000.S6787@godot.imp.ch> References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <20070310012921.I6787@godot.imp.ch> <20070311091617.GG2887@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , gerald@freebsd.org, Julian Elischer , freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 10:13:00 -0000 Hi, > http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003674.html > http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003682.html Well explained, thanks. Maybe it would help to have something like this in the manpages. It would be cool if a 'man pthreads' explains it too. -- Martin From owner-freebsd-threads@FreeBSD.ORG Sun Mar 11 17:58:19 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FA9316A401 for ; Sun, 11 Mar 2007 17:58:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outW.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD4913C468 for ; Sun, 11 Mar 2007 17:58:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sun, 11 Mar 2007 10:31:36 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 43B0B125B39; Sun, 11 Mar 2007 10:58:18 -0700 (PDT) Message-ID: <45F4433A.8010707@elischer.org> Date: Sun, 11 Mar 2007 10:58:18 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Jeremie Le Hen References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <20070310012921.I6787@godot.imp.ch> <20070311091617.GG2887@obiwan.tataz.chchile.org> In-Reply-To: <20070311091617.GG2887@obiwan.tataz.chchile.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Martin Blapp , gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 17:58:19 -0000 Jeremie Le Hen wrote: > Hi Martin, > > On Sat, Mar 10, 2007 at 01:32:26AM +0100, Martin Blapp wrote: >> Hi, >> >>> There is no portable way to identify threads in another process. There is >>> also no guarantee that the tread is even externally visible. Take >> But is it true for FreeBSD that 'ps -Hauxwww' should show all threads >> for a process with libc_r, libpthreads.so, or libthr.so ? > > May I advice you to read these two posts for a thorough explanation. > > http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003674.html > http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003682.html > This is true, however it is a bit out of date because the thread group facility that gives scheduler fairness (talked about in the second reference) has been ripped out of -current due to no-body thinking it was needed. and a general thought that the added complexity was not worth the result. Generally it made the scheduler much more complicated. What is said about SA is however still true if that threading facility is chosen. it still leads to some scheduler fairness as only NCPU threads from the process are put onto the kernel run queue at a time. From owner-freebsd-threads@FreeBSD.ORG Sun Mar 11 18:01:33 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88DE216A400 for ; Sun, 11 Mar 2007 18:01:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outR.internet-mail-service.net (outR.internet-mail-service.net [216.240.47.241]) by mx1.freebsd.org (Postfix) with ESMTP id 7BAB913C458 for ; Sun, 11 Mar 2007 18:01:33 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Sun, 11 Mar 2007 10:34:50 -0700 Received: from [192.168.2.5] (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 2BCA9125B80; Sun, 11 Mar 2007 11:01:32 -0700 (PDT) Message-ID: <45F443FB.7090703@elischer.org> Date: Sun, 11 Mar 2007 11:01:31 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Martin Blapp References: <200703091515.27133.tijl@ulyssis.org> <200703092100.12199.tijl@ulyssis.org> <45F1DD68.8040103@elischer.org> <20070310012921.I6787@godot.imp.ch> <20070311091617.GG2887@obiwan.tataz.chchile.org> <20070311111000.S6787@godot.imp.ch> In-Reply-To: <20070311111000.S6787@godot.imp.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , gerald@freebsd.org, freebsd-threads@freebsd.org Subject: Re: signalling remote threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2007 18:01:33 -0000 Martin Blapp wrote: > > Hi, > >> http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003674.html >> >> http://lists.freebsd.org/pipermail/freebsd-threads/2006-August/003682.html >> > > Well explained, thanks. Maybe it would help to have something like this > in the manpages. It would be cool if a 'man pthreads' explains it too. man kse sort of does. though as I said in other email some of the features mentioned in the references, while accurately described and theoretically useful, have been removed. > > -- > Martin > > > _______________________________________________ > 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 owner-freebsd-threads@FreeBSD.ORG Mon Mar 12 11:08:40 2007 Return-Path: X-Original-To: freebsd-threads@FreeBSD.org Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83DC216A4D1 for ; Mon, 12 Mar 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 6B36213C484 for ; Mon, 12 Mar 2007 11:08:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2CB8edx065233 for ; Mon, 12 Mar 2007 11:08:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2CB8dbU065229 for freebsd-threads@FreeBSD.org; Mon, 12 Mar 2007 11:08:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Mar 2007 11:08:39 GMT Message-Id: <200703121108.l2CB8dbU065229@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2007 11:08:40 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o threa/90278 threads libthr, ULE and -current produces >100% WCPU with apac o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc f threa/98256 threads gnome-system-monitor core dumps from pthread_testcance s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash 28 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/81534 threads [libc_r] [patch] libc_r close() will fail on any fd ty 9 problems total. From owner-freebsd-threads@FreeBSD.ORG Wed Mar 14 23:10:03 2007 Return-Path: X-Original-To: freebsd-threads@hub.freebsd.org Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD5EE16A400 for ; Wed, 14 Mar 2007 23:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id B933713C4BC for ; Wed, 14 Mar 2007 23:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l2ENA3lk026641 for ; Wed, 14 Mar 2007 23:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l2ENA3in026640; Wed, 14 Mar 2007 23:10:03 GMT (envelope-from gnats) Resent-Date: Wed, 14 Mar 2007 23:10:03 GMT Resent-Message-Id: <200703142310.l2ENA3in026640@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Oles Hnatkevych Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76E2216A400 for ; Wed, 14 Mar 2007 23:03:23 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [69.147.83.33]) by mx1.freebsd.org (Postfix) with ESMTP id 597D013C44B for ; Wed, 14 Mar 2007 23:03:23 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l2EN3MQN056444 for ; Wed, 14 Mar 2007 23:03:22 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id l2EN3MPP056443; Wed, 14 Mar 2007 23:03:22 GMT (envelope-from nobody) Message-Id: <200703142303.l2EN3MPP056443@www.freebsd.org> Date: Wed, 14 Mar 2007 23:03:22 GMT From: Oles Hnatkevych To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.0 Cc: Subject: threads/110306: apache 2.0 segmentation violation when calling gethostbyname X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 23:10:03 -0000 >Number: 110306 >Category: threads >Synopsis: apache 2.0 segmentation violation when calling gethostbyname >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 14 23:10:03 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Oles Hnatkevych >Release: 6.2-STABLE >Organization: >Environment: FreeBSD murzik.oles.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Thu Dec 28 17:06:26 EET 2006 root@murzik.oles.net:/usr/obj/usr/src/sys/MURZIK i386 >Description: "apachectl restart" causes apache httpd process to dump core: Mar 15 00:32:27 murzik kernel: pid 95239 (httpd), uid 0: exited on signal 11 (core dumped) The problem happens if php module is loaded and ServerName is not defined in httpd.conf. It's believed that the problem happens on FreeBSD only and the cause of the problem is bug in threading functions, not the apache or php bug. Apache is 2.0.59, php is 5.1.5 (but seems to be irrelevant) The backtrace: (gdb) bt full #0 0x28d1a034 in ?? () No symbol table info available. #1 0x28427832 in pthread_main_np_int () at /usr/src/lib/libc/gen/_pthread_stubs.c:183 No locals. #2 0x2840595e in __hostdata_init () at /usr/src/lib/libc/net/gethostnamadr.c:67 he = (struct hostdata *) 0xbfbfebf4 #3 0x28406264 in gethostbyname (name=0xbfbfe5b0 "murzik.oles.net") at /usr/src/lib/libc/net/gethostnamadr.c:363 hd = (struct hostdata *) 0x0 rval = (struct hostent *) 0xa ret_h_errno = 675506452 #4 0x08070f11 in ap_get_local_host (a=0x80a6018) at util.c:2045 str = "murzik.oles.net\000\000\000\000\000\001\000\000\000\002\000\000\000N\2203(▒忿\n\000\000\002\000\000\000\000\004\000\000\000\001\000\000\000P▒3(H濿\031▒2(y▒\026\b0濿\020\000\000\000\215▒2(y4\vD▒꿿\000▒\026\bn▒2(\204▒\026\b4濿\004\000\000\000X▒2(h\2203(\001\000\000\000\002\000\000\000N\2203(7濿\n\000\000\002\000\000\000\000\004\000\000\000\001\000\000\000P▒3(x濿\021▒2(y▒\026\b\204▒\026\bH翿▒▒2(@=I(▒▒\t\b\002\000\000\000\002\000\000\000\001\000\000\000P▒3("... server_hostname = 0x0 p = (struct hostent *) 0x816c500 #5 0x0806cdc7 in ap_fini_vhost_config (p=0x80a6018, main_s=0x80a7df8) at vhost.c:535 sar = (server_addr_rec *) 0x0 has_default_vhost_addr = 135445688 s = (server_rec *) 0x80a7df8 i = 134897688 iphash_table_tail = {0x40, 0x80b2968, 0x0, 0x28438480, 0x2844d9e4, 0x82a8140, 0xbfbfe7c8, 0x283c2b29, 0x80a6018, 0x8, 0xbfbfe748, 0x806db14, 0x6c, 0x80b29d0, 0x3, 0x80b29d0, 0x80b2858, 0x80b2000, 0x0, 0x0, 0x755, 0x41ed0008, 0xbfbfe778, 0x2832aec5, 0xbfbfe874, 0x45f849ec, 0x2832ae2c, 0x41ed, 0x2833a150, 0x809817c, 0xbfbfe808, 0x2832b236, 0xbfbfe830, 0xbfbfe7a0, 0x8000, 0x2832b1d0, 0x0, 0x0, 0x0, 0x0, 0x5b, 0x12b197, 0x1d41ed, 0x3ed, 0x50, 0x4ab48d, 0x45f877e2, 0x0, 0x45f849ec, 0x0, 0x45f849ec, 0x0, 0x600, 0x8134c08, 0x4, 0x8134c08, 0x1000, 0x8134000, 0xbfbfe818, 0x284732ae, 0x80a6018, 0x8, 0xbfbfe828, 0x28473259, 0x81349a8, 0x2833a150, 0x8134c09, 0x28474f99, 0x28476470, 0x81347f8, 0xbfbfe858, 0x284733e1, 0x80a6018, 0x81349bc, 0xbfbfe894, 0x284733b9, 0x8134990, 0x80a6018, 0x1e, 0x28327688, 0x1, 0x18, 0xbfbfe868, 0x28474f98, 0x28476470, 0x2833a150, 0xbfbfe898, 0x283283c1, 0x8134c18, 0xbfbfeafc, 0x809817c, 0x2832815d, 0x8134f40, 0x48, 0x8134f3b, 0x10, 0x50415448, 0x4, 0x8134f40, 0x8134d30, 0x2847b178, 0x809817c, 0xbfbfe8c8, 0x2847abef, 0x8134c18, 0x8134f38, 0x8134f40, 0x2847aba0, 0x8134da8, 0x8091f20, 0xbfbfedf8, 0x8134c18, 0x8134c10, 0x81260e4, 0xbfbfe938, 0x8067cc1, 0x80a6018, 0xbfbfe94c, 0x8134f38, 0x2847aa48, 0x2847b020, 0xa, 0xbfbfe908, 0x2847aa09, 0x81260b0, 0x2847ae41, 0x8134580, 0x8134c10, 0x1, 0x809817c, 0xbfbfe928, 0x8067fd4, 0x81341b0, 0x2847b080, 0x8134c10, 0x0, 0x0, 0x0, 0xbfbfe968, 0x806851e, 0x8091f20, 0x1, 0xbfbfe968, 0x8068550, 0x2847b020, 0xbfbfeac0, 0x8134c10, 0x81260e4, 0x80a6018, 0x0, 0x0, 0x8134c10, 0x2847b020, 0x2847b080, 0xbfbfe998, 0x80685e4, 0x81260c0, 0xbfbfeac0, 0x81341b0, 0x8069823, 0x80a6018, 0x80b3ea3, 0x80b3ea8, 0x0, 0x0, 0x80f34d8, 0xbfbfe9d8, 0x807c264, 0x0, 0xbfbfeac0, 0x81341b0, 0xbfbfe9d0, 0x0, 0x8095300, 0x0, 0x0, 0x0, 0x80a6018, 0x8122ed3, 0x0, 0x80b3ea8, 0x80a7df8, 0xbfbfea48, 0x80676a0, 0xbfbfeac0, 0x80f35e8, 0x80b3e98, 0x1, 0x8095330, 0xbfbfeafc, 0xbfbfea18, 0x8067ee2, 0x8122e98, 0x8094196, 0xa, 0x28327436, 0x1, 0x80b4720, 0xbfbfea48, 0x80799c4...} #6 0x0806c478 in main (argc=1, argv=0xbfbfebec) at main.c:623 c = 0 '\0' configtestonly = 0 confname = 0x809184c "etc/apache2/httpd.conf" def_server_root = 0x8091863 "/usr/local" temp_error_log = 0x0 process = (process_rec *) 0x80a4090 server_conf = (server_rec *) 0x80a7df8 pglobal = (apr_pool_t *) 0x80a4018 pconf = (apr_pool_t *) 0x80a6018 plog = (apr_pool_t *) 0x80d2018 ptemp = (apr_pool_t *) 0x80f1018 pcommands = (apr_pool_t *) 0x80a8018 opt = (apr_getopt_t *) 0x80a80b0 rv = 70014 mod = (module **) 0x809801c optarg = 0x2809e9a1 "\215e▒[\211▒^_▒▒▒\214▒▒▒▒▒\211▒U\211▒WVS\203▒8▒" signal_server = (apr_OFN_ap_signal_server_t *) 0 (gdb) >How-To-Repeat: Install ports www/apache20 and lang/php5, run apache server, run "apachectl restart" >Fix: Only workaround is known: define ServerName in httpd.conf >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Thu Mar 15 12:12:13 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76E6416A402; Thu, 15 Mar 2007 12:12:13 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id E6F5213C44B; Thu, 15 Mar 2007 12:12:12 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-02.forthnet.gr (8.14.0/8.14.0) with ESMTP id l2F8gYKC012269; Thu, 15 Mar 2007 10:42:34 +0200 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-03.forthnet.gr (8.13.7/8.13.7) with ESMTP id l2F8gUEr031596; Thu, 15 Mar 2007 10:42:34 +0200 Received: from [192.168.136.22] (ppp97-184.adsl.forthnet.gr [212.54.207.184]) by MX-IN-01.forthnet.gr (8.14.0/8.14.0) with ESMTP id l2F8gPi8003629; Thu, 15 Mar 2007 10:42:25 +0200 Authentication-Results: MX-IN-01.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <45F906ED.8070100@aueb.gr> Date: Thu, 15 Mar 2007 10:42:21 +0200 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org, freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Multithreaded qsort(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 12:12:13 -0000 Greetings, I've added multhread support to our qsort implementation. You can see the code at and some performance figures at the end of this email. I propose to add it to our libc. I need your opinions on the interface, and also any comments you may have on the code. I see the following design dimensions: 1. Naming and availability -------------------------- - Option 1.1: Replace qsort with this implementation * Pros: Programs gain performance without any source code change; abstraction (number of processors/cores should be invisible, just as the CPU architecture or disk drive interface) * Cons: May confuse multithreaded programs; programs require linking with pthreads library; programs whose compare function is not thread safe will break - Option 1.2: Name it qsort_mt * Pros: POLA; programs can tune the call according to their need * Cons: Programs require source code changes; we violate abstraction; namespace polution My proposal: option 1.2: name it qsort_mt and make it available in a separate library (libc_mt). 2. Interface ------------ - Option 2.1: qsort compatible * Pros: Drop in replacement; doesn't need programmer understanding; compatible with option 1.1 * Cons: Can't be tuned for a specific program or workload - Option 2.2: Add nthreads parameter, specifying the maximum number of threads * Pros: Multithreaded programs can tune load balancing; all programs can optimise nthreads according to the workload characteristics. * Cons: Libc routines are generaly expected to Do he Right Thing, without handholding; must agree on mechanism for determining the number of threads; the benefits of tuning are unlikely to be dramatic. - Option 2.3: Add forkelem, specifying minimum number of elements for a new thread (below forkelem, I use single-threaded qsort). * Pros: programs can optimise nthreads according to the workload characteristics. * Cons: Libc routines are generaly expected to Do he Right Thing, without handholding; the benefits of tuning are unlikely to be dramatic. - Option 2.4: Have the library tune itsself for a given system or individual programs by measuring different values * Pros: higher performance when the tuned values are reused * Cons: Lack of prior art; performance drop when determining tuning values; security considerations if values are cached; complexity (Options 2.2 and 2.3 are orthogonal; options 2.1 and 2.4 are orthogonal) My proposal: go for 2.1, based on the way C library routines work. 3. Determining the number of threads ------------------------------------ - Option 3.1: NPROCS environment variable * Pros: prior art: CrayOS, BSD/OS; users can tune it. * Cons: May be too blunt; requires setting by user or administrator - Option 3.[234]: hw.ncpu or kern.smp.cpus sysctl, or pmc_ncpu() * Pros: automatic, right for the underlying hardware * Cons: even blunter - Option 3.5: Add library interface for the above as int nthreads_mt() * Pros: we abstract policy; programs can replace it; reusability; extensibility. * Cons: namespace polution; it is not clear that a single number is correct for all uses of a program. (All the above options are orthogonal) My proposal: Add library interface using NPROCS and falling back to a sysctl variable. This interface can be extended in the future. Performance figures ------------------- Reported times are elapsed, user, and system seconds. $ uname -a FreeBSD sledge.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #924: Wed Mar 14 14:25:07 UTC 2007 root@sledge.freebsd.org:/h/src/sys/amd64/compile/SLEDGE amd64 $ qsort_mt -? qsort_mt: option requires an argument -- h usage: qsort_mt [-stv] [-f forkelements] [-h threads] [-n elements] -l Run the libc version of qsort -s Test with 20-byte strings, instead of integers -t Print timing results -v Verify the integer results Defaults are 1e7 elements, 2 threads, 100 fork elements $ gcc -DTEST -O qsort_mt.c -o qsort_mt -lthr -lpmc $ qsort_mt -t -h 2 -n 100000000 -l # Integers; qsort(3) 46.5 46.2 0.314 $ ./qsort_mt -t -h 2 -n 100000000 # Integers; qsort_mt 27.5 46.3 0.301 $ qsort_mt -t -h 2 -n 10000000 -s -l # Strings; qsort(3) 41.3 40.1 1.2 $ ./qsort_mt -t -h 2 -n 10000000 -s # Strings; qsort_mt 26.7 40.1 1.16 $ gcc -DTEST -O qsort_mt.c -o qsort_mt -lpthread -lpmc $ qsort_mt -t -h 2 -n 100000000 # Integers; qsort_mt 28 47.1 0.368 $ qsort_mt -t -h 2 -n 10000000 -s # Strings; qsort_mt 27.1 40.6 1.06 Thanks, Diomidis - dds@ http://www.spinellis.gr From owner-freebsd-threads@FreeBSD.ORG Thu Mar 15 13:34:11 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E2E416A403; Thu, 15 Mar 2007 13:34:11 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtai104.cox.net (eastrmmtai104.cox.net [68.230.240.11]) by mx1.freebsd.org (Postfix) with ESMTP id AFC5613C45A; Thu, 15 Mar 2007 13:34:10 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao105.cox.net (InterMail vM.7.05.02.00 201-2174-114-20060621) with ESMTP id <20070315124215.FFRR16421.eastrmmtao105.cox.net@eastrmimpo02.cox.net>; Thu, 15 Mar 2007 08:42:15 -0400 Received: from mezz.mezzweb.com ([24.255.149.218]) by eastrmimpo02.cox.net with bizsmtp id b0iD1W0044iy4EG0000000; Thu, 15 Mar 2007 08:42:14 -0400 Date: Thu, 15 Mar 2007 07:44:03 -0500 To: "Diomidis Spinellis" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 References: <45F906ED.8070100@aueb.gr> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <45F906ED.8070100@aueb.gr> User-Agent: Opera Mail/9.10 (Linux) Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Multithreaded qsort(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 13:34:11 -0000 On Thu, 15 Mar 2007 03:42:21 -0500, Diomidis Spinellis wrote: > Greetings, > > I've added multhread support to our qsort implementation. You can see > the code at and some > performance figures at the end of this email. I propose to add it to > our libc. I need your opinions on the interface, and also any comments > you may have on the code. I see the following design dimensions: That remind me other days when I have readed in one of blog that have some good info about sorts. I will posting a few of links in here in case if anyone is insteresting to read. ;-) Quick Sort (qsort()): http://jeffreystedfast.blogspot.com/2007/03/quick-sort.html 25 Byte Sort Routine: http://jeffreystedfast.blogspot.com/2007/03/25-byte-sort-routine.html Merge Sort: http://jeffreystedfast.blogspot.com/2007/02/merge-sort.html A lot of more sorts: Shell Sort Binary Insertion Sort Insertion Sort Bubble Sort http://jeffreystedfast.blogspot.com/search/label/sorting Cheers, Mezz > 1. Naming and availability > -------------------------- > - Option 1.1: Replace qsort with this implementation > * Pros: Programs gain performance without any source code change; > abstraction (number of processors/cores should be invisible, just as the > CPU architecture or disk drive interface) > * Cons: May confuse multithreaded programs; programs require linking > with pthreads library; programs whose compare function is not thread > safe will break > > - Option 1.2: Name it qsort_mt > * Pros: POLA; programs can tune the call according to their need > * Cons: Programs require source code changes; we violate abstraction; > namespace polution > > My proposal: option 1.2: name it qsort_mt and make it available in a > separate library (libc_mt). > > > 2. Interface > ------------ > - Option 2.1: qsort compatible > * Pros: Drop in replacement; doesn't need programmer understanding; > compatible with option 1.1 > * Cons: Can't be tuned for a specific program or workload > > - Option 2.2: Add nthreads parameter, specifying the maximum number of > threads > * Pros: Multithreaded programs can tune load balancing; all programs can > optimise nthreads according to the workload characteristics. > * Cons: Libc routines are generaly expected to Do he Right Thing, > without handholding; must agree on mechanism for determining the number > of threads; the benefits of tuning are unlikely to be dramatic. > > - Option 2.3: Add forkelem, specifying minimum number of elements for a > new thread (below forkelem, I use single-threaded qsort). > * Pros: programs can optimise nthreads according to the workload > characteristics. > * Cons: Libc routines are generaly expected to Do he Right Thing, > without handholding; the benefits of tuning are unlikely to be dramatic. > > - Option 2.4: Have the library tune itsself for a given system or > individual programs by measuring different values > * Pros: higher performance when the tuned values are reused > * Cons: Lack of prior art; performance drop when determining tuning > values; security considerations if values are cached; complexity > > (Options 2.2 and 2.3 are orthogonal; options 2.1 and 2.4 are orthogonal) > > My proposal: go for 2.1, based on the way C library routines work. > > 3. Determining the number of threads > ------------------------------------ > - Option 3.1: NPROCS environment variable > * Pros: prior art: CrayOS, BSD/OS; users can tune it. > * Cons: May be too blunt; requires setting by user or administrator > > - Option 3.[234]: hw.ncpu or kern.smp.cpus sysctl, or pmc_ncpu() > * Pros: automatic, right for the underlying hardware > * Cons: even blunter > > - Option 3.5: Add library interface for the above as int nthreads_mt() > * Pros: we abstract policy; programs can replace it; reusability; > extensibility. > * Cons: namespace polution; it is not clear that a single number is > correct for all uses of a program. > > (All the above options are orthogonal) > > My proposal: Add library interface using NPROCS and falling back to a > sysctl variable. This interface can be extended in the future. > > Performance figures > ------------------- > Reported times are elapsed, user, and system seconds. > > $ uname -a > FreeBSD sledge.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #924: Wed Mar > 14 14:25:07 UTC 2007 > root@sledge.freebsd.org:/h/src/sys/amd64/compile/SLEDGE amd64 > > $ qsort_mt -? > qsort_mt: option requires an argument -- h > usage: qsort_mt [-stv] [-f forkelements] [-h threads] [-n elements] > -l Run the libc version of qsort > -s Test with 20-byte strings, instead of integers > -t Print timing results > -v Verify the integer results > Defaults are 1e7 elements, 2 threads, 100 fork elements > > > $ gcc -DTEST -O qsort_mt.c -o qsort_mt -lthr -lpmc > > $ qsort_mt -t -h 2 -n 100000000 -l # Integers; qsort(3) > 46.5 46.2 0.314 > $ ./qsort_mt -t -h 2 -n 100000000 # Integers; qsort_mt > 27.5 46.3 0.301 > $ qsort_mt -t -h 2 -n 10000000 -s -l # Strings; qsort(3) > 41.3 40.1 1.2 > $ ./qsort_mt -t -h 2 -n 10000000 -s # Strings; qsort_mt > 26.7 40.1 1.16 > > $ gcc -DTEST -O qsort_mt.c -o qsort_mt -lpthread -lpmc > $ qsort_mt -t -h 2 -n 100000000 # Integers; qsort_mt > 28 47.1 0.368 > $ qsort_mt -t -h 2 -n 10000000 -s # Strings; qsort_mt > 27.1 40.6 1.06 > > > Thanks, > > Diomidis - dds@ > http://www.spinellis.gr -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org http://wiki.freebsd.org/multimedia - multimedia@FreeBSD.org From owner-freebsd-threads@FreeBSD.ORG Thu Mar 15 15:01:58 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA2FF16A400; Thu, 15 Mar 2007 15:01:58 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from blue.servers.aueb.gr (blue.servers.aueb.gr [195.251.255.132]) by mx1.freebsd.org (Postfix) with ESMTP id 8616413C448; Thu, 15 Mar 2007 15:01:58 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from [195.251.254.141] ([::ffff:195.251.254.141]) by blue.servers.aueb.gr with esmtp; Thu, 15 Mar 2007 16:51:54 +0200 id 000D1229.45F95D8A.00002F17 Message-ID: <45F95D87.9070108@aueb.gr> Date: Thu, 15 Mar 2007 16:51:51 +0200 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: Ivan Voras References: <45F906ED.8070100@aueb.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Multithreaded qsort(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 15:01:58 -0000 Ivan Voras wrote: > Diomidis Spinellis wrote: >> I've added multhread support to our qsort implementation. You can see >> the code at and some > > Interesting idea. I remember talks about OpenMP in gcc 4.2 - maybe it > would be better to do it with OpenMP? I'm not sure that OpenMP is mature and flexible enough for this. My understanding is that the performance of a recursive algorithm, like qsort, would depend on the compiler's support for what is termed "nested parallelism". It would certainly save me effort, but given that I've written it, this is now a moot point. I compared my implementation against the qsort available in OmpSCR (OpenMP Source Code Repository) on a Sun Niagara (Sun-Fire-T200 - 4 processors with 4 cores each). As you can see the speedup of the OpenMP implementation above two threads is nonexistent. Even for two threads, my implementation gets a speedup of 34% and the OpenMP one 26%. Of course, this can well be a problem of the specific qsort implementation. Sun C 5.8 Patch 121015-04 2007/01/10 OmpSCR c_qsort.par compiled with -xopenmp=parallel # THREADS SIZE STEPS TIME (secs.) 1 1000000 10 46.919788 2 1000000 10 34.391163 4 1000000 10 34.465052 8 1000000 10 34.427057 qsort_mt compiles with cc -O qsort_mt.c -DTEST -xc99=all -o qsort_mt # THREADS SIZE STEPS TIME (secs.) 1 50000000 1 39.5 2 50000000 1 26 4 50000000 1 20.5 8 50000000 1 16.6 16 50000000 1 16.1 Diomidis From owner-freebsd-threads@FreeBSD.ORG Thu Mar 15 17:40:34 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F35516A401 for ; Thu, 15 Mar 2007 17:40:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id E925C13C489 for ; Thu, 15 Mar 2007 17:40:33 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.64.186.120] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1HRtjw0TZu-0000eb; Thu, 15 Mar 2007 18:27:51 +0100 From: Max Laier Organization: FreeBSD To: freebsd-arch@freebsd.org Date: Thu, 15 Mar 2007 18:27:32 +0100 User-Agent: KMail/1.9.5 References: <45F906ED.8070100@aueb.gr> In-Reply-To: <45F906ED.8070100@aueb.gr> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5645397.FyxE2rQ9mp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200703151827.39963.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+lropN8exSTmzfKWjeHkRJZMf83DcCdPzLYTe C5UWS1kvJsPZmiRJ/UrEMzCAz8Tte7QCzs6hX3oWbCdJmYL0EL VC2uibCBz+9YbsWR0jDqQ== Cc: freebsd-threads@freebsd.org Subject: Re: Multithreaded qsort(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 17:40:34 -0000 --nextPart5645397.FyxE2rQ9mp Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 15 March 2007 09:42, Diomidis Spinellis wrote: > Greetings, > > I've added multhread support to our qsort implementation. You can see > the code at and some > performance figures at the end of this email. I propose to add it to > our libc. I need your opinions on the interface, and also any comments > you may have on the code. I see the following design dimensions: > > 1. Naming and availability > -------------------------- > - Option 1.1: Replace qsort with this implementation > * Pros: Programs gain performance without any source code change; > abstraction (number of processors/cores should be invisible, just as > the CPU architecture or disk drive interface) > * Cons: May confuse multithreaded programs; programs require linking > with pthreads library; programs whose compare function is not thread > safe will break > > - Option 1.2: Name it qsort_mt > * Pros: POLA; programs can tune the call according to their need > * Cons: Programs require source code changes; we violate abstraction; > namespace polution > > My proposal: option 1.2: name it qsort_mt and make it available in a > separate library (libc_mt). I'd suggest to name it qsort() and put it in a separate library (not=20 necessarily named libc_mt, as I don't believe there are that many=20 functions in libc, that can actually gain from multithreading). This approach, would allow LD_PRELOAD'ing the _mt version without the need= =20 to recompile. That said, I'm not sure this really belongs in the base system. As=20 qsort_mt it's way too obscure and unportable for any real application to=20 use it. As a replacement for qsort it won't work (as you pointed out=20 yourself). I do think that we need efforts like this, but they should be=20 made outside of FreeBSD, otherwise they won't be much useful in general. > 2. Interface > ------------ > - Option 2.1: qsort compatible > * Pros: Drop in replacement; doesn't need programmer understanding; > compatible with option 1.1 > * Cons: Can't be tuned for a specific program or workload > > - Option 2.2: Add nthreads parameter, specifying the maximum number of > threads > * Pros: Multithreaded programs can tune load balancing; all programs > can optimise nthreads according to the workload characteristics. > * Cons: Libc routines are generaly expected to Do he Right Thing, > without handholding; must agree on mechanism for determining the number > of threads; the benefits of tuning are unlikely to be dramatic. > > - Option 2.3: Add forkelem, specifying minimum number of elements for a > new thread (below forkelem, I use single-threaded qsort). > * Pros: programs can optimise nthreads according to the workload > characteristics. > * Cons: Libc routines are generaly expected to Do he Right Thing, > without handholding; the benefits of tuning are unlikely to be > dramatic. > > - Option 2.4: Have the library tune itsself for a given system or > individual programs by measuring different values > * Pros: higher performance when the tuned values are reused > * Cons: Lack of prior art; performance drop when determining tuning > values; security considerations if values are cached; complexity > > (Options 2.2 and 2.3 are orthogonal; options 2.1 and 2.4 are > orthogonal) > > My proposal: go for 2.1, based on the way C library routines work. > > 3. Determining the number of threads > ------------------------------------ > - Option 3.1: NPROCS environment variable > * Pros: prior art: CrayOS, BSD/OS; users can tune it. > * Cons: May be too blunt; requires setting by user or administrator > > - Option 3.[234]: hw.ncpu or kern.smp.cpus sysctl, or pmc_ncpu() > * Pros: automatic, right for the underlying hardware > * Cons: even blunter > > - Option 3.5: Add library interface for the above as int nthreads_mt() > * Pros: we abstract policy; programs can replace it; reusability; > extensibility. > * Cons: namespace polution; it is not clear that a single number is > correct for all uses of a program. > > (All the above options are orthogonal) > > My proposal: Add library interface using NPROCS and falling back to a > sysctl variable. This interface can be extended in the future. > > Performance figures > ------------------- > Reported times are elapsed, user, and system seconds. > > $ uname -a > FreeBSD sledge.freebsd.org 7.0-CURRENT FreeBSD 7.0-CURRENT #924: Wed > Mar 14 14:25:07 UTC 2007 > root@sledge.freebsd.org:/h/src/sys/amd64/compile/SLEDGE amd64 > > $ qsort_mt -? > qsort_mt: option requires an argument -- h > usage: qsort_mt [-stv] [-f forkelements] [-h threads] [-n elements] > -l Run the libc version of qsort > -s Test with 20-byte strings, instead of integers > -t Print timing results > -v Verify the integer results > Defaults are 1e7 elements, 2 threads, 100 fork elements > > > $ gcc -DTEST -O qsort_mt.c -o qsort_mt -lthr -lpmc > > $ qsort_mt -t -h 2 -n 100000000 -l # Integers; qsort(3) > 46.5 46.2 0.314 > $ ./qsort_mt -t -h 2 -n 100000000 # Integers; qsort_mt > 27.5 46.3 0.301 > $ qsort_mt -t -h 2 -n 10000000 -s -l # Strings; qsort(3) > 41.3 40.1 1.2 > $ ./qsort_mt -t -h 2 -n 10000000 -s # Strings; qsort_mt > 26.7 40.1 1.16 > > $ gcc -DTEST -O qsort_mt.c -o qsort_mt -lpthread -lpmc > $ qsort_mt -t -h 2 -n 100000000 # Integers; qsort_mt > 28 47.1 0.368 > $ qsort_mt -t -h 2 -n 10000000 -s # Strings; qsort_mt > 27.1 40.6 1.06 > > > Thanks, > > Diomidis - dds@ > http://www.spinellis.gr > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart5645397.FyxE2rQ9mp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBF+YILXyyEoT62BG0RAju3AJ4vEppT5JGbBZYcyhTi/oaeTvkv2QCfV8PG zAnh7BCCQi8z2Ag7I2OAeJI= =CehS -----END PGP SIGNATURE----- --nextPart5645397.FyxE2rQ9mp-- From owner-freebsd-threads@FreeBSD.ORG Thu Mar 15 18:21:37 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A55C16A402; Thu, 15 Mar 2007 18:21:37 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9A413C4B9; Thu, 15 Mar 2007 18:21:36 +0000 (UTC) (envelope-from gergely.czuczy@harmless.hu) Received: from localhost (marvin-mail [192.168.0.2]) by marvin.harmless.hu (Postfix) with ESMTP id 70D117BFF20; Thu, 15 Mar 2007 18:49:48 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at harmless.hu Received: from marvin.harmless.hu ([192.168.0.2]) by localhost (marvin.harmless.hu [192.168.0.2]) (amavisd-new, port 10024) with ESMTP id 9WLi6L+l4vwJ; Thu, 15 Mar 2007 18:49:48 +0100 (CET) Received: from marvin.harmless.hu (localhost [127.0.0.1]) by marvin.harmless.hu (Postfix) with ESMTP id DB5A47BFD14; Thu, 15 Mar 2007 18:49:47 +0100 (CET) Date: Thu, 15 Mar 2007 18:49:47 +0100 From: Gergely CZUCZY To: Max Laier Message-ID: <20070315174947.GA4674@harmless.hu> References: <45F906ED.8070100@aueb.gr> <200703151827.39963.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: <200703151827.39963.max@love2party.net> User-Agent: mutt-ng/devel-r804 (FreeBSD) Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Multithreaded qsort(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2007 18:21:37 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2007 at 06:27:32PM +0100, Max Laier wrote: > On Thursday 15 March 2007 09:42, Diomidis Spinellis wrote: > > Greetings, > > > > I've added multhread support to our qsort implementation. You can see > > the code at and some > > performance figures at the end of this email. I propose to add it to > > our libc. I need your opinions on the interface, and also any comments > > you may have on the code. I see the following design dimensions: > > > > 1. Naming and availability > > -------------------------- > > - Option 1.1: Replace qsort with this implementation > > * Pros: Programs gain performance without any source code change; > > abstraction (number of processors/cores should be invisible, just as > > the CPU architecture or disk drive interface) > > * Cons: May confuse multithreaded programs; programs require linking > > with pthreads library; programs whose compare function is not thread > > safe will break > > > > - Option 1.2: Name it qsort_mt > > * Pros: POLA; programs can tune the call according to their need > > * Cons: Programs require source code changes; we violate abstraction; > > namespace polution > > > > My proposal: option 1.2: name it qsort_mt and make it available in a > > separate library (libc_mt). >=20 > I'd suggest to name it qsort() and put it in a separate library (not=20 > necessarily named libc_mt, as I don't believe there are that many=20 > functions in libc, that can actually gain from multithreading). >=20 > This approach, would allow LD_PRELOAD'ing the _mt version without the nee= d=20 > to recompile. >=20 > That said, I'm not sure this really belongs in the base system. As=20 > qsort_mt it's way too obscure and unportable for any real application to= =20 > use it. As a replacement for qsort it won't work (as you pointed out=20 > yourself). I do think that we need efforts like this, but they should be= =20 > made outside of FreeBSD, otherwise they won't be much useful in general. I'm just a FreeBSD user, and developing some applications under it. I'd like to share my point of view, a point of view of an application developer, of this placing. I see two useful ways placing such a function into the OS. One is naming it qsort() and putting it into a library that even can be libmaped or preloaded into some applications, thus gaining some performance on some applications that were not designed to be work in a multithreaded way (and gain performa= nce on the several CPUs). The other one is putting it into a different library, that a program can be linked against along with libc, and the old qsort and this new one can be mixed as the developers would like it to. By this way, it would be very useful to have the ability to assign control functions to the multihreaded qsort, like telling it what threads to use, how to lunch/reuse threads, how many, and so on. To be honest, i find both ways quite useful. I think maybe the best way would be to do both at the same time. Bye, Gergely Czuczy mailto: gergely.czuczy@harmless.hu --=20 Weenies test. Geniuses solve problems that arise. --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) owF1Vz1sHEUUNoloVlCYinIkCtvJ3fl8cexwxobEDlGEE1uJEUIUYXZ39m7i3Zn1 zOydNxIICQkoKBANSBQgqJEogJKehoKGlhaElIKKju/N7J3vYnBh383u+/u+7703 /uTZiwsXFn/57vu3Ln/86RdPffvMr/GlonJODdoFNyOp2mvd7lp7fWNzvb3R7vXW 1wXnm+tJ91p3fe3azX8+3NrVygnl2kd1KfrMiVO3WuZcqi2WDLmxwm1XLmtfiybv 7Ulbaiud1KrPpMqlEtNnR4YrmwnTvqkSnUo16LOTSjuRtksjleNxLqLoQLGjYdVi d7hha1dbrNftbjLuWHej39vsX+kd3mGXu8ia3jhl+1wKw8YGXvrRDgvGxqa8hjH5 SIbBQ/fF/nqvxfakLmQqLbtfIrM8x6ep8Q67ZYRwyMu26Ks/ur00EoynqUhZUeVu aARPma3KUhvHnGa6MuzE0hdZlLkoUCen4juMvakrlnDFrBDelRsKhroFVfPS0Lmy v7paCg2rTobAsU072gxW301Tu+pdPihcJ9lhXCGiLoKTUphMm4KrRLBMDiojLPkj 3wLv6QwfUZQouMyRw21WGg1CBOWKMpikrL0nyjyXceLfUgIF1nSkAQzyt0wr7xXE ICRPRMsnwnMLR6pGJQUVa70vWLICmA850GoMqVTvG/X7g0znuR4DXpYKKweKpRIe LAXrT/Fe67C7vKCXfLQRyuCxzKWr/eP2//6Ex+ygJPThZq3P7glIFTgFfsbSDQM4 80x5w0vs0Gjbp98DwwvLBtD4HNhkrivna7cAKmnIRBuogdjyXnhsneGJz2BZVUUM bYIRUJAIiyTsaqKJMAtPecpiQnckrYTwW+xhZeHdTqWye/g6I/1KJxIHnpk2QMwe s9TI0QwvK00Bu4QjJE/UqKwC5SRYGSQLdsumtK3pJ2bESSXhGV16DMi9Iw9TGaws CcRwU8/YjIekJrBfclhmlQrlAlalSYdk5x1ZnhFqec5inB1PGZ7hqNcnsgWJciL4 eTYO9q/PhKZmcpUKako4PPMEgNIkIXnjVBqv5DlEDp+s9jx7wGQs2EjqnDsxy2Kg VSFHW5KSSp1XE834R3fqpsF43kfrnNWlnqjLy7ngx/6wkXVOLDIe0BLAk6I3iLNl 6k0YrnSine1eN6JRRJNngHT95JmLsLziA5QQKI7I6394BEHBkxKkR25kXns3KWuC occtOjbVaslBnrkUI482UCO23RCjBu1QBzcT8i0FJA+t8AbxBPwqMFSHRsqMLmbl CMbO6jqinuQlcOTJsMXGvjc4zQq2v/fg8N7N/YPre0ueZPBOWI6EobEx7Uk6B+/b URo8Ah0jSKISs/UsDFKzXKYtIFl4tdrKFyVJGz5ZlKwx/qke8hlzSN3W1okCk+y6 DY6mlEq3hH5AwzmNRRDbhNwRDZWi9eAJxvzwI4MCUJG5TPzUgc12FPxRq0rnA4A2 E4YWjSdv3CwXzC9PylibY7YMlmjklpqmAKZ+1RBLE9yKPFvxgzelnkBrB1bGIkx5 kcGto9Y+DsW3WBwwrM8G0yS3AqOD3FtJfzP2KhbVjft7LaZJFWNpRTAcN4oBydi4 qCirckJxIJQwPO9EBHmYcBMf9JYJSyWFzHJaPAO/6GZxsgAzxRglgNAAUchaI1MS ZFEHDCi1kRRjuJs/oL+kxhngm2CIHU22JSGO4J0oarbVWE9qAL3T59ALiuMzQ0+F scMO7ndw9xB+CobtJV30RGO6cByM+LQrPTdISfm2iX27FrwkVg1mC1Kl6R15q3Pg UMNVYVlNwZtdWsjxnE3UqAHwUQ+EXYxw8I/oXl9+fsxvD5L5MlUytxi3I0SJmoVv UQW4psVl0d3REc68TJCGh+Y8CKnMcB8kqTdwNBOET4Z+A0pEGwpZcIpOIqI2Dasq zB3KjHLQUG/omHBChJAKlJh4KuQpObL+9akWbDN2vLz8HanDbtTBAUpvhQZsljbK rKNGHyjDX3rIW3NR8Vct62842MTO6HxmUjaC8eA22AahtJqGpEtpwGg85JOF6u0Q scWGmIr4nMPhcNWIyjegf8U/i2g6t5orI8omGjyvQ0BgEUTi1oiHMYgJ2sZOxI4I 1aDFmomBy1wciopp3eDNaFo+wmOyeA/NzdPSKnK4zSHcjVq0ouiWMAOBgbr7qEoe 1RHdRp3uYxz4407ij19BDxc5NlFnWEVRu00j5w0hlMQVySFsh93CF6SGG5POATJE gZla2EYkBuOnE3308sWnF+hflcm/OYsXHn298NVnOx/c/funhz/+cPWFK+/vvP3e 4vOf/77w5Wt/Re/8+dv65Y3dk+ce//x48Y/TC9/8Cw== =nogL -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-threads@FreeBSD.ORG Fri Mar 16 00:37:28 2007 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64B7216A402; Fri, 16 Mar 2007 00:37:28 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id C08FF13C43E; Fri, 16 Mar 2007 00:37:27 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l2G0PZgf016667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Mar 2007 02:25:41 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.13.8/8.13.8) with ESMTP id l2G0PHrS027895; Fri, 16 Mar 2007 02:25:28 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.13.8/8.13.8/Submit) id l2G0PG6C027798; Fri, 16 Mar 2007 02:25:16 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Fri, 16 Mar 2007 02:25:16 +0200 From: Giorgos Keramidas To: Max Laier Message-ID: <20070316002515.GA66354@kobe.laptop> References: <45F906ED.8070100@aueb.gr> <200703151827.39963.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703151827.39963.max@love2party.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.765, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.63, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-threads@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Multithreaded qsort(3) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2007 00:37:28 -0000 On 2007-03-15 18:27, Max Laier wrote: > On Thursday 15 March 2007 09:42, Diomidis Spinellis wrote: > > Greetings, > > > > I've added multhread support to our qsort implementation. You can see > > the code at and some > > performance figures at the end of this email. I propose to add it to > > our libc. I need your opinions on the interface, and also any comments > > you may have on the code. I see the following design dimensions: > > > > 1. Naming and availability > > -------------------------- > > - Option 1.1: Replace qsort with this implementation > > * Pros: Programs gain performance without any source code change; > > abstraction (number of processors/cores should be invisible, just as > > the CPU architecture or disk drive interface) > > * Cons: May confuse multithreaded programs; programs require linking > > with pthreads library; programs whose compare function is not thread > > safe will break > > > > - Option 1.2: Name it qsort_mt > > * Pros: POLA; programs can tune the call according to their need > > * Cons: Programs require source code changes; we violate abstraction; > > namespace polution > > > > My proposal: option 1.2: name it qsort_mt and make it available in a > > separate library (libc_mt). > > I'd suggest to name it qsort() and put it in a separate library (not > necessarily named libc_mt, as I don't believe there are that many > functions in libc, that can actually gain from multithreading). > > This approach, would allow LD_PRELOAD'ing the _mt version without the > need to recompile. > > That said, I'm not sure this really belongs in the base system. As > qsort_mt it's way too obscure and unportable for any real application > to use it. As a replacement for qsort it won't work (as you pointed > out yourself). I do think that we need efforts like this, but they > should be made outside of FreeBSD, otherwise they won't be much useful > in general. Does it make sense to put all the thread/performance-related functions of this sort in libmt.so and allow either explicit linking with -lmt or preloading the library whenever needed? This way we can keep generally useful MT-safe functions in libmt.so and let people choose when they use them :)