From owner-freebsd-threads@FreeBSD.ORG Sun Nov 28 00:10:13 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7524B1065670 for ; Sun, 28 Nov 2010 00:10:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 48B868FC12 for ; Sun, 28 Nov 2010 00:10:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAS0ADgq065800 for ; Sun, 28 Nov 2010 00:10:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAS0AD6D065799; Sun, 28 Nov 2010 00:10:13 GMT (envelope-from gnats) Date: Sun, 28 Nov 2010 00:10:13 GMT Message-Id: <201011280010.oAS0AD6D065799@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Mikko Tyolajarvi Cc: Subject: Re: threads/24472: libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket options X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mikko Tyolajarvi List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Nov 2010 00:10:13 -0000 The following reply was made to PR threads/24472; it has been noted by GNATS. From: Mikko Tyolajarvi To: bug-followup@FreeBSD.org Cc: Subject: Re: threads/24472: libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket options Date: Sat, 27 Nov 2010 15:33:22 -0800 Hi, I submitted this bug from an email address that has now been defunct for years. As far as I can tell after some basic testing, FreeBSD 7-stable, 8-stable and 9-current do not have this problem. I think this bug can safely be closed. Thanks, /Mikko From owner-freebsd-threads@FreeBSD.ORG Mon Nov 29 11:07:12 2010 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FD381065673 for ; Mon, 29 Nov 2010 11:07:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E62468FC12 for ; Mon, 29 Nov 2010 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oATB7BZc053226 for ; Mon, 29 Nov 2010 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oATB7Bbb053224 for freebsd-threads@FreeBSD.org; Mon, 29 Nov 2010 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Nov 2010 11:07:11 GMT Message-Id: <201011291107.oATB7Bbb053224@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org 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, 29 Nov 2010 11:07:12 -0000 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/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/149366 threads pthread_cleanup_pop never runs the configured routine o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 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/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. f threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa 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 s threa/69020 threads pthreads library leaks _gc_mutex 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/34536 threads accept() blocks other threads s threa/30464 threads pthread mutex attributes -- pshared f threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 31 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Nov 29 15:43:00 2010 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49AF51065679; Mon, 29 Nov 2010 15:43:00 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1E9EC8FC23; Mon, 29 Nov 2010 15:43:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oATFh0Sf047705; Mon, 29 Nov 2010 15:43:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oATFgxS4047701; Mon, 29 Nov 2010 15:42:59 GMT (envelope-from linimon) Date: Mon, 29 Nov 2010 15:42:59 GMT Message-Id: <201011291542.oATFgxS4047701@freefall.freebsd.org> To: mikko@dynas.se, linimon@FreeBSD.org, freebsd-threads@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: threads/24472: libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket options 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, 29 Nov 2010 15:43:00 -0000 Synopsis: libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket options State-Changed-From-To: feedback->closed State-Changed-By: linimon State-Changed-When: Mon Nov 29 15:42:36 UTC 2010 State-Changed-Why: Submitter notes that this can be closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=24472 From owner-freebsd-threads@FreeBSD.ORG Tue Nov 30 07:56:13 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86E95106564A for ; Tue, 30 Nov 2010 07:56:13 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 648C28FC08 for ; Tue, 30 Nov 2010 07:56:13 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PNKo1-0003zf-LH for freebsd-threads@freebsd.org; Mon, 29 Nov 2010 23:39:17 -0800 Message-ID: <30337545.post@talk.nabble.com> Date: Mon, 29 Nov 2010 23:39:17 -0800 (PST) From: p4ddy To: freebsd-threads@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: prdpsbhat@gmail.com X-Mailman-Approved-At: Tue, 30 Nov 2010 12:09:27 +0000 Subject: Creating thread dynamically in a thread pool 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: Tue, 30 Nov 2010 07:56:13 -0000 Hi all, Here is the story. I m handling threads for some server. maxThreadPoolSize is given as 1000 but obviously creating 1000 threads not only takes time but also huge resources. So am thinking of creating threads dynamically for the thread pool. Initially say 100 threads will be created and based on certain factors, more number of threads will be created and added to the pool. As I m new to thread pooling, i have certain doubts: 1. how to determine initial number of threads? currently i have set it to 100 2. how to determine when to create next batch of threads? currently i m creating another batch of threads as soon as the number of active threads reaches 70% of the total threads. 3. what should be the batch size? currently i have set it to 100. so with every batch, 100 threads will be added to the pool 4. another doubt is regarding memory allocation. currently i m allocating memory to all the 1000 threads initially but threads are getting created only when there is a requirement. Is this good? or should i allocate memory dynamically too? Hope to get some answers/opinions :) Thanks in advance. -- View this message in context: http://old.nabble.com/Creating-thread-dynamically-in-a-thread-pool-tp30337545p30337545.html Sent from the freebsd-threads mailing list archive at Nabble.com. From owner-freebsd-threads@FreeBSD.ORG Tue Nov 30 13:26:12 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31BC4106566B for ; Tue, 30 Nov 2010 13:26:12 +0000 (UTC) (envelope-from gofdt-freebsd-threads@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id DDE6E8FC14 for ; Tue, 30 Nov 2010 13:26:11 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PNPz7-000872-2T for freebsd-threads@freebsd.org; Tue, 30 Nov 2010 14:11:05 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Nov 2010 14:11:04 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Nov 2010 14:11:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-threads@freebsd.org From: Ivan Voras Date: Tue, 30 Nov 2010 14:11:03 +0100 Lines: 15 Message-ID: References: <30337545.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <30337545.post@talk.nabble.com> X-Enigmail-Version: 1.1.2 Subject: Re: Creating thread dynamically in a thread pool 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: Tue, 30 Nov 2010 13:26:12 -0000 On 11/30/10 08:39, p4ddy wrote: > > Hi all, > > Here is the story. > > I m handling threads for some server. maxThreadPoolSize is given as 1000 but > obviously creating 1000 threads not only takes time but also huge resources. Obviously I don't know what your particular constraints are, but creating 1000 threads takes a few milliseconds and produces a process with resident size of 25 MB and a VM size of 135 MB. (on amd64) It could well be that those are huge resources for you, I don't know :) From owner-freebsd-threads@FreeBSD.ORG Tue Nov 30 16:04:00 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F83E1065672 for ; Tue, 30 Nov 2010 16:04:00 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 1AFE48FC12 for ; Tue, 30 Nov 2010 16:04:00 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PNSgR-0004QT-HD for freebsd-threads@freebsd.org; Tue, 30 Nov 2010 08:03:59 -0800 Message-ID: <30340939.post@talk.nabble.com> Date: Tue, 30 Nov 2010 08:03:59 -0800 (PST) From: p4ddy To: freebsd-threads@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: prdpsbhat@gmail.com References: <30337545.post@talk.nabble.com> X-Mailman-Approved-At: Tue, 30 Nov 2010 17:07:18 +0000 Subject: Re: Creating thread dynamically in a thread pool 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: Tue, 30 Nov 2010 16:04:00 -0000 Yeah, for 1000 threads that is ok. But what is the case if the thread size is 10000. that is an example i mentioned but the problem here is to create threads dynamically based on certain criteria. :) Ivan Voras-7 wrote: > > On 11/30/10 08:39, p4ddy wrote: >> >> Hi all, >> >> Here is the story. >> >> I m handling threads for some server. maxThreadPoolSize is given as 1000 >> but >> obviously creating 1000 threads not only takes time but also huge >> resources. > > Obviously I don't know what your particular constraints are, but > creating 1000 threads takes a few milliseconds and produces a process > with resident size of 25 MB and a VM size of 135 MB. (on amd64) > > It could well be that those are huge resources for you, I don't know :) > > > _______________________________________________ > 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" > > -- View this message in context: http://old.nabble.com/Creating-thread-dynamically-in-a-thread-pool-tp30337545p30340939.html Sent from the freebsd-threads mailing list archive at Nabble.com. From owner-freebsd-threads@FreeBSD.ORG Fri Dec 3 14:11:36 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B18A51065696 for ; Fri, 3 Dec 2010 14:11:36 +0000 (UTC) (envelope-from markus.henschel@yager.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4387B8FC12 for ; Fri, 3 Dec 2010 14:11:36 +0000 (UTC) Received: from mail.yager.de (mail.yager.de [212.60.243.130]) by mx02.qsc.de (Postfix) with ESMTP id 1F5CC1E26F for ; Fri, 3 Dec 2010 14:51:38 +0100 (CET) Received: from hermes.corp.yager.de ([fe80::8de:db45:75d8:9f78]) by hermes.corp.yager.de ([fe80::8de:db45:75d8:9f78%12]) with mapi; Fri, 3 Dec 2010 14:51:37 +0100 From: Markus Henschel To: "freebsd-threads@freebsd.org" Date: Fri, 3 Dec 2010 14:51:36 +0100 Thread-Topic: Influence ULE Interactivity Rating Thread-Index: AcuS8TP7RxDalBUFSKeolI4NqzQipg== Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Influence ULE Interactivity Rating 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, 03 Dec 2010 14:11:36 -0000 Hello, I'm working on an app that has a main thread consistently drawing to the sc= reen (30 time per second, opengl). There are several background threads for= different tasks like decoding compressed video data or doing disk IO. I us= e libthr.so with ULE under FreeBSD 7.1 in a semi embedded environment. When waking up background threads from the main thread we observe that the = main thread sometimes blocks for a fairly long time like 100ms or more. It = mostly happens when the background threads slept for some time. This behavi= or is quite problematic because it causes stuttering in the animations rend= ered by the main thread. These hangs get shorter or disappear when the back= ground threads do not sleep for so long. After reading how the ULE scheduler works I think it might be caused by the= interactivity scoring. These background threads may sleep a long time befo= re they wake up so the scheduler thinks they are interactive. Is this possi= ble? Assuming the interactivity scoring is the problem: How can I influence= it on a per thread or per process basis other than spending more cpu cycle= s in the background threads?=20 This is what I tried so far: 1. Use another scheduling policy and priorities. This didn't help much. In fact very strange deadlocks occurred rendering th= e whole system unusable. Not even a ssh login was possible.=20 2. I tried to work around the problem by letting the background threads pol= l their task queues instead of waiting for a condition to be notified. This= completely removes the hangs of the main thread but is quite inefficient a= nd creates problems on other target platforms for our multi platform app es= pecially for larger numbers of background threads. 3. Tweak the synctl parameter kern.shed.interac. This seems to help. I trie= d these combinations: a) kern.shed.interact=3D0 In this case no process should be considered as being interactive, I think = (Am I right?). The hanging of the main thread is still present but much sho= rter. b) kern.shed.interact=3Dmax This works best so far. The main thread doesn't hang at all anymore.=20 But changing kern.shed.interact influences all other processes and disables= boosting priority of interactive processes/threads completely. I cannot re= ally foresee what other problems this creates in other applications. 5. Split up the work in the background threads into smaller chunks and rele= ase the cpu as often as possible.=20 I did this for one thread that should write a screenshot to disk. This is d= one line by line with a call to pthread_yield after every line. This had no= influence on the hangs. Furthermore it is not possible in all circumstance= s. But it is interesting that even though the background thread voluntarily= releases the cpu the main thread still is not executed for such a long per= iod of time. 6. Set the background threads to RTP_PRIO_IDLE by calling rtprio_thread. This removed the hanging of the main thread but is not a good thing for all= background threads. Furthermore it might cause starvation of the backgroun= d threads when there are no spare cpu cycles for some reason. (7. Use another threading library.=20 I didn't test this yet.) The system is a 2GHZ Celeron (single core), x86. I also tested this on free= bsd 8.1 system with similar results.=20 Any suggestions are very welcome. Markus Henschel Lead Programmer YAGER Development GmbH Pfuelstra=DFe 5 10997 Berlin Germany www.yager.de Sitz der Gesellschaft: Berlin | Gesch=E4ftsf=FChrer: Timo Ullmann, Uwe Bene= ke Amtsgericht Berlin-Charlottenburg | HRB 78261 | USt-ID-Nr. DE 212404124 From owner-freebsd-threads@FreeBSD.ORG Sat Dec 4 15:53:35 2010 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DBA8106566B for ; Sat, 4 Dec 2010 15:53:35 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-ew0-f51.google.com (mail-ew0-f51.google.com [209.85.215.51]) by mx1.freebsd.org (Postfix) with ESMTP id 07ABF8FC0C for ; Sat, 4 Dec 2010 15:53:34 +0000 (UTC) Received: by ewy19 with SMTP id 19so8293181ewy.10 for ; Sat, 04 Dec 2010 07:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=JEDxlRPA8qRf2RGiXMnDRsbjCT2oxTEsl3S2PiftNeE=; b=ipXF9YWwwHFAwct/Lelt40l2MY5VboE0fhm+CPuAewQ+rigyIif0blXfQ5Do6CnqnP fOX6BTAX2jYzpY02XW8NL37EHTWcKTzB6LekjQI5YRMeDJZAWLuztPDKeSWyyLhN5oea lLNuiFPonhIDaKGuDluWeqyOavf5hOHKmRl8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=uaCV71Z+VmydGkZPzugQT0EWQfYmE1dNbswMyiqPg/KQrawT6Hhnmoq8E7WYLapvna CrxkhwVuZd87HUZq5V5cI5qHvhEq93Kp74WYoRTQ/gPW7/xsarW242yM43tzC+q7ToCM sPwH60N+CgxBiusLFzRUO5gPcQhEmIxqUXPcM= Received: by 10.213.105.211 with SMTP id u19mr455774ebo.21.1291476602834; Sat, 04 Dec 2010 07:30:02 -0800 (PST) Received: from ernst.jennejohn.org (p578E19E7.dip.t-dialin.net [87.142.25.231]) by mx.google.com with ESMTPS id w20sm2675598eeh.18.2010.12.04.07.30.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 04 Dec 2010 07:30:02 -0800 (PST) Date: Sat, 4 Dec 2010 16:29:59 +0100 From: Gary Jennejohn To: Markus Henschel Message-ID: <20101204162959.34ef2920@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.7 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-threads@freebsd.org" Subject: Re: Influence ULE Interactivity Rating X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 15:53:35 -0000 On Fri, 3 Dec 2010 14:51:36 +0100 Markus Henschel wrote: > Hello, > > I'm working on an app that has a main thread consistently drawing to the screen (30 time per second, opengl). There are several background threads for different tasks like decoding compressed video data or doing disk IO. I use libthr.so with ULE under FreeBSD 7.1 in a semi embedded environment. > > When waking up background threads from the main thread we observe that the main thread sometimes blocks for a fairly long time like 100ms or more. It mostly happens when the background threads slept for some time. This behavior is quite problematic because it causes stuttering in the animations rendered by the main thread. These hangs get shorter or disappear when the background threads do not sleep for so long. > > After reading how the ULE scheduler works I think it might be caused by the interactivity scoring. These background threads may sleep a long time before they wake up so the scheduler thinks they are interactive. Is this possible? Assuming the interactivity scoring is the problem: How can I influence it on a per thread or per process basis other than spending more cpu cycles in the background threads? > > > This is what I tried so far: > > 1. Use another scheduling policy and priorities. > This didn't help much. In fact very strange deadlocks occurred rendering the whole system unusable. Not even a ssh login was possible. > > 2. I tried to work around the problem by letting the background threads poll their task queues instead of waiting for a condition to be notified. This completely removes the hangs of the main thread but is quite inefficient and creates problems on other target platforms for our multi platform app especially for larger numbers of background threads. > > 3. Tweak the synctl parameter kern.shed.interac. This seems to help. I tried these combinations: > a) kern.shed.interact=0 > In this case no process should be considered as being interactive, I think (Am I right?). The hanging of the main thread is still present but much shorter. > > b) kern.shed.interact=max > This works best so far. The main thread doesn't hang at all anymore. > > But changing kern.shed.interact influences all other processes and disables boosting priority of interactive processes/threads completely. I cannot really foresee what other problems this creates in other applications. > > 5. Split up the work in the background threads into smaller chunks and release the cpu as often as possible. > I did this for one thread that should write a screenshot to disk. This is done line by line with a call to pthread_yield after every line. This had no influence on the hangs. Furthermore it is not possible in all circumstances. But it is interesting that even though the background thread voluntarily releases the cpu the main thread still is not executed for such a long period of time. > > 6. Set the background threads to RTP_PRIO_IDLE by calling rtprio_thread. > This removed the hanging of the main thread but is not a good thing for all background threads. Furthermore it might cause starvation of the background threads when there are no spare cpu cycles for some reason. > > (7. Use another threading library. > I didn't test this yet.) > > The system is a 2GHZ Celeron (single core), x86. I also tested this on freebsd 8.1 system with similar results. > > Any suggestions are very welcome. > [entire text left for context] Try SCHED_BSD, I don't think it's designed to optimize interactivity the way ULE was. Doesn't seem like you really need that. I've seen reports that switching can improve performance. -- Gary Jennejohn