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