From patchwork Thu Mar 10 01:54:40 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: glenvt18 X-Patchwork-Id: 33421 Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.84) (envelope-from ) id 1adpoN-0001kn-HJ; Thu, 10 Mar 2016 01:54:47 +0000 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.84) (envelope-from ) id 1adpoJ-0001kO-US for vdr@linuxtv.org; Thu, 10 Mar 2016 01:54:45 +0000 X-tubIT-Incoming-IP: 209.85.213.43 Received: from mail-vk0-f43.google.com ([209.85.213.43]) by mail.tu-berlin.de (exim-4.76/mailfrontend-5) with esmtps [UNKNOWN:AES128-GCM-SHA256:128] for id 1adpoI-0001PC-8H; Thu, 10 Mar 2016 02:54:43 +0100 Received: by mail-vk0-f43.google.com with SMTP id c3so78805515vkb.3 for ; Wed, 09 Mar 2016 17:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=05tPBzJwDZQOP/30KPar2HwUma9/0wdj1qTsGg0hcVg=; b=z7pCLEIfHg/pu9WMuXsbshJ6vVwLTJd8Y+JPfuCnMKkgOjAMsDHbwP0aWFc5nBnLLz HVvbj+fUSAhZ/OI5J0zUAAq6ZLcn7oWjs4X9DbC282yZWyqeX2T9rVJ1b2T+3jRWF0w+ wLXbK3S1fDgs2XLrwUZNorp1BM1dGX0XujpIi/caW44+WbXITt6keDRxd1bQQ1KXKjeY poCeiVQQ8wnEkBLGmM07CXnShimWydrfGxZ/kOZh1SGv0ou7EmWo83yC3IxGzHKIrpOI KgYfbBskEpJXWCiG1Ms+QEikjj16p5wnWYuwsfGS+oda8ZaJtW8O+4FEyxe9JI4Rh9He KYkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=05tPBzJwDZQOP/30KPar2HwUma9/0wdj1qTsGg0hcVg=; b=QVz4dAIwIt4RTj55QN4l8zdyDCorxDs4Ovs47/Q/bLS8vs5l5evHivL3ZrrmEfCJjW PscUnu6VrMhyYrKtIkpCFx7D3MGsEW/iz7eV1ZNxe7ns1XfAf6aXdj4mx1J9XOE0XVeL jg0toVh7jEUh31JPi7nPpuEvuHmxhbaDgtv8c8vCRNZ+0RZCGtvX7zCNGdRToBV7K+KF XgbqKnOZTOf0m5A+am7BEVt6h6MJC0OVrxb8HiIphXo7cgF2Jr4Azw9+ioI/qP1jw/3e dUSj9tDq52zWQ7vHkbbvElkyax8cJkJm8Bmsgh13h23ETCEM5COE4k/gVmKPYsaq5ex1 81kA== X-Gm-Message-State: AD7BkJLj1R+MQUBuZYuogHW+7yiVegMq5p+JzN9rf4Y4s1A5OCBn/mNHfBcRlax7VP9dc0Rfh6qscjmM46jWjA== MIME-Version: 1.0 X-Received: by 10.31.139.132 with SMTP id n126mr975060vkd.78.1457574880804; Wed, 09 Mar 2016 17:54:40 -0800 (PST) Received: by 10.31.161.17 with HTTP; Wed, 9 Mar 2016 17:54:40 -0800 (PST) Date: Thu, 10 Mar 2016 04:54:40 +0300 Message-ID: From: glenvt18 To: vdr@linuxtv.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.10.14516 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' FROM_NAME_ONE_WORD 0.05, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1300_1399 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, CT_TEXT_PLAIN_UTF8_CAPS 0, DKIM_SIGNATURE 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, WEBMAIL_SOURCE 0, __CT 0, __CT_TEXT_PLAIN 0, __DATE_TZ_RU 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __RDNS_GMAIL 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __YOUTUBE_RCVD 0' X-LSpam-Score: 0.8 (/) X-LSpam-Report: No, score=0.8 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RDNS_NONE=1.274, T_DKIM_INVALID=0.01 autolearn=no autolearn_force=no Subject: [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" 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); } } }