From patchwork Thu Mar 10 09:41:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 33427 Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.84) (envelope-from ) id 1adx6U-0006vE-KB; Thu, 10 Mar 2016 09:41:58 +0000 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.84) (envelope-from ) id 1adx6S-0006v5-7E for vdr@linuxtv.org; Thu, 10 Mar 2016 09:41:56 +0000 X-tubIT-Incoming-IP: 88.198.76.220 Received: from racoon.tvdr.de ([88.198.76.220]) by mail.tu-berlin.de (exim-4.76/mailfrontend-8) with esmtps [UNKNOWN:AES256-GCM-SHA384:256] for id 1adx6Q-0007xW-ly; Thu, 10 Mar 2016 10:41:56 +0100 Received: from dolphin.tvdr.de (dolphin.tvdr.de [192.168.1.2]) by racoon.tvdr.de (8.14.9/8.14.9) with ESMTP id u2A9frVZ001044 for ; Thu, 10 Mar 2016 10:41:53 +0100 Received: from [192.168.1.11] (falcon.tvdr.de [192.168.1.11]) by dolphin.tvdr.de (8.14.4/8.14.4) with ESMTP id u2A9frCU014087 for ; Thu, 10 Mar 2016 10:41:53 +0100 To: VDR Mailing List References: From: Klaus Schmidinger Message-ID: <56E14161.3050307@tvdr.de> Date: Thu, 10 Mar 2016 10:41:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.10.93316 X-PMX-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __USER_AGENT 0' X-LSpam-Score: 1.3 (+) X-LSpam-Report: No, score=1.3 required=5.0 tests=RDNS_NONE=1.274 autolearn=no autolearn_force=no Subject: Re: [vdr] [PATCH] Fix TS buffer thread high CPU usage X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: VDR Mailing List Errors-To: vdr-bounces@linuxtv.org Sender: "vdr" On 10.03.2016 02:54, glenvt18 wrote: > Hi folks, > > I've found that with some DVB tuner drivers poll() returns when there > are only small (1-3) number of TS packets available to read(). This > results in high CPU usage of the TS buffer thread which is busy > reading small chunks of data in cTSBuffer::Action(). 2 out of 3 tuners > I tested were affected with this issue. Even with a "good" tuner TS > buffer thread CPU usage is up to 10% per HD stream on ARM Cortex-A7. > With the proposed patch it is below 1-2% on all ARM and x86_64 > platforms I've tested. The delay value of 10 ms can be considered > safe: > > media/dvb-core/dmxdev.h:109 > #define DVR_BUFFER_SIZE (10*188*1024) > > It will take a tuner to receive (10*188*1024)*8*(1000/10) / 1000000 = > 1540 Mbit/s to overflow the device buffer within 10 ms interval. A > smaller delay is not enough for ARM. cDvbDevice has a ring buffer of > 5MB which is larger. > > This patch was made against VDR 2.3.1, but it can be applied to VDR > 2.2.0 as well. > > Please review. > glenvt18 > --- > Index: b/device.c > =================================================================== > --- a/device.c 2015-09-18 01:04:12.000000000 +0300 > +++ b/device.c 2016-03-10 03:38:50.078400715 +0300 > @@ -1768,6 +1768,8 @@ > break; > } > } > + else > + cCondWait::SleepMs(10); > } > } > } I'm not too fond of the idea of introducing an additional, unconditional wait here. The actual problem should be fixed within the drivers. However, maybe waiting in case there is only a small number of TS packets available is acceptable: The number MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE is just a random pick to avoid using a concrete literal number here. Can you please test if this still solves your problem? Klaus --- device.c 2015/09/05 11:42:17 4.2 +++ device.c 2016/03/10 09:34:11 @@ -1768,6 +1768,8 @@ break; } } + else if (r < MIN_TS_PACKETS_FOR_FRAME_DETECTOR * TS_SIZE) + cCondWait::SleepMs(10); } } }