From patchwork Fri Apr 6 03:48:19 2007 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "C.Y.M" X-Patchwork-Id: 12449 Received: from ik-out-1112.google.com ([66.249.90.182]) by www.linuxtv.org with esmtp (Exim 4.50) id 1HZfQy-00051I-RQ for vdr@linuxtv.org; Fri, 06 Apr 2007 05:48:20 +0200 Received: by ik-out-1112.google.com with SMTP id b35so551325ika for ; Thu, 05 Apr 2007 20:48:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=g4GlBkpusPX+miNxYDfQJMKqrpetDjKyI/2mY/89P/82Oq8c/jw2e5L8+8ECjjY0IAp//1uF7Cgs3uFwEbzePQF/RfaQ5odfuqonBT4z2kPLUTEtXwN34fyMxeo8Szc6mtvkPJjMj0lbyUQ52sclC1wcfTfTPIwB4zDQpta5SO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OSOr2nOSTlvPjhAr/dbUcyaJypiCLzrR8hwkn52fyI2Rna4bs+cqnQ2aPyrcJmziccDuiwcpUmumpvSLN6Z0yvlN1sQamfJa1J74eMCFxPP7+JayqIb1OgGLZiSIpYfbMk14g5PP+kxus2kB578S0CXBtRYfGJvVWdF0hmTyAvE= Received: by 10.78.192.20 with SMTP id p20mr462995huf.1175831299497; Thu, 05 Apr 2007 20:48:19 -0700 (PDT) Received: by 10.78.29.11 with HTTP; Thu, 5 Apr 2007 20:48:19 -0700 (PDT) Message-ID: <2d842fa80704052048x624fccafk7d0517234edf6a4f@mail.gmail.com> Date: Thu, 5 Apr 2007 20:48:19 -0700 From: Stone To: "VDR Mailing List" Subject: Re: [vdr] [PATCH] limit streamdev client's ringbuffer timeouts to more sane values In-Reply-To: <46157B8A.2030801@o2.pl> MIME-Version: 1.0 References: <46157B8A.2030801@o2.pl> X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2007 03:48:20 -0000 Status: O X-Status: X-Keywords: X-UID: 12621 On 4/5/07, Artur Skawina wrote: > > Well, the streamdev-client reads data from a ringbuffer and when there > isn't anything > to read it tries to sleep for 1us and loops. This wasn't a problem when > the timer > resolution was in the 1000..10000us range (1000..100Hz); the usleep(1) > call slept > for one or more milliseconds. > With the high-res timers in kernel 2.6.21+ usleep(1) is no longer treated > as > usleep(10000) and the streamdev client is almost unusable; it uses most of > the cpu > and causes hundreds of thousands context switches per second. > This gets rid of the almost-busy-loop. How about his approach? --- streamdev/client/filter.c.orig 2007-04-05 20:45:04.000000000 -0700 +++ streamdev/client/filter.c 2007-04-05 20:45:44.000000000 -0700 @@ -135,7 +135,7 @@ } m_RingBuffer->Del(TS_SIZE); } else - usleep(1); + cCondWait::SleepMs(1); } }