Date: Sat, 4 Dec 2010 16:29:59 +0100 From: Gary Jennejohn <gljennjohn@googlemail.com> To: Markus Henschel <markus.henschel@yager.de> Cc: "freebsd-threads@freebsd.org" <freebsd-threads@freebsd.org> Subject: Re: Influence ULE Interactivity Rating Message-ID: <20101204162959.34ef2920@ernst.jennejohn.org> In-Reply-To: <B6A6EF22B0D16146BD127139E7667DDB0747B09262@hermes.corp.yager.de> References: <B6A6EF22B0D16146BD127139E7667DDB0747B09262@hermes.corp.yager.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Dec 2010 14:51:36 +0100 Markus Henschel <markus.henschel@yager.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101204162959.34ef2920>