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