Date: Fri, 3 Dec 2010 14:51:36 +0100 From: Markus Henschel <markus.henschel@yager.de> To: "freebsd-threads@freebsd.org" <freebsd-threads@freebsd.org> Subject: Influence ULE Interactivity Rating Message-ID: <B6A6EF22B0D16146BD127139E7667DDB0747B09262@hermes.corp.yager.de>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B6A6EF22B0D16146BD127139E7667DDB0747B09262>