From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751579AbbE0KiP (ORCPT ); Wed, 27 May 2015 06:38:15 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:49200 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750902AbbE0KiM (ORCPT ); Wed, 27 May 2015 06:38:12 -0400 X-AuditID: cbfee68d-f79106d00000728c-fa-55659e9295a4 Date: Wed, 27 May 2015 10:38:10 +0000 (GMT) From: EunTaik Lee Subject: Re: Re: [RFC PATCH] suspend/resume performance improvement To: Pavel Machek Cc: "rjw@rjwysocki.net" , "len.brown@intel.com" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Reply-to: eun.taik.lee@samsung.com MIME-version: 1.0 X-MTR: 20150527085021638@eun.taik.lee Msgkey: 20150527085021638@eun.taik.lee X-EPLocale: ko_KR.euc-kr X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-MLAttribute: X-RootMTR: 20150527085021638@eun.taik.lee X-ParentMTR: X-ArchiveUser: EV X-CPGSPASS: N X-ConfirmMail: N,general Content-type: text/plain; charset=euc-kr MIME-version: 1.0 Message-id: <2002354124.810441432723088778.JavaMail.weblogic@epmlwas01d> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDJsWRmVeSWpSXmKPExsVy+t8zPd1J81JDDea/Nre4vGsOmwOjx+dN cgGMUQ2MNolFyRmZZakKqXnJ+SmZeem2SqEhbroWSgoZ+cUltkrRRgbGekamJnpGJuZ6lgax VkamSgp5ibmptkoVulC9SgpFyQVAtbmVxUADclL1oOJ6xal5KQ5Z+aUgl+gVJ+YWl+al6yXn 5yoplCXmlAKNUNJPmMqY8fjDT+aCZ3wVTy9+YWxg3MDXxcjJISSgLnFi9xoWEFtCwERi4dt3 TBC2mMSFe+vZuhi5gGqWMUosnXmHCaZo5oJdrBCJOYwSa4+2gSVYBFQlds/+yQZiswnoSvz/ 2MUOYgsLOEt0db4Ai4sIKEosapvMCNLMLHCFUWL/g8NMEGcoScw/3AB2Bq+AoMTJmU+gTlKV OPFsNytEXE1i8ZwHbBBxCYlZ0y+wQti8EjPan0LVy0lM+7qGGcKWljg/awMjzDuLvz+GivNL HLu9A+obAYmpZw5C1WhJtF7fAzWHT2LNwrdQtqDE6WvdzDC77m+ZywRzw9aWJ2A3MAM9NqX7 ITuErSXx5cc+NnS/8Ap4SOx8dxtqzlQOiS2NmRMYlWYhKZuFZNQsJKOQ1SxgZFnFKJpakFxQ nJReZIgc35sYIcmwdwfj7QPWhxgFOBiVeHgzJFNDhVgTy4orcw8xJgPjaSKzlGhyPjDl5pXE GxqbGVmYmpgaG5lbmmEIm5haWJgY4RBWEudVlPoZLCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoGx+9u/kiKdg2GtMztfZEVGJN89YuNpUCspHshbJFSS52Hy+VBp4ZpNUsG/elVEC9IvGpS+ WNDEpnzrQhTrtgauqXmrri78LXnUTXf5xqiJZr4vJtVsetPSqsHvpZqmsHtV+sMlD9XOCV+M 4CrbFRwiPkNWkcvWhbX874/br8Lb77S6icn+T1NiKc5INNRiLipOBACcN9XSrwMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFKsWRmVeSWpSXmKPExsVy+t/tPt1J81JDDT5fM7G4vGsOmwOjx+dN cgGMURk2GamJKalFCql5yfkpmXnptkrewfHO8aZmBoa6hpYW5koKeYm5qbZKLj4Bum6ZOUBD lRTKEnNKgUIBicXFSvp2NkX5pSWpChn5xSW2StFGBsZ6RqYmekbGBnomBrFWhgYGRqZAVQkZ GY8//GQueMZX8fTiF8YGxg18XYycHEIC6hIndq9hAbElBEwkZi7YxQphi0lcuLeerYuRC6hm DqPE2qNtTCAJFgFVid2zf7KB2GwCuhL/P3axg9jCAs4SXZ0vwOIiAooSi9omM4I0MwtcYZTY /+AwE8Q2JYn5hxvAtvEKCEqcnPkEarOqxIlnu1kh4moSi+c8YIOIS0jMmn4B6iJeiRntT6Hq 5SSmfV3DDGFLS5yftYER5urF3x9Dxfkljt3ewQRhC0hMPXMQqkZLovX6Hqg5fBJrFr6FsgUl Tl/rZobZdX/LXCaYG7a2PAG7gRnosSndD9khbC2JLz/2saH7hVfAQ2Lnu9vMExhlZyFJzULS PgtJO7KaBYwsqxhFUwuSC4qT0iuM9IoTc4tL89L1kvNzNzGC09GzRTsY/523PsQowMGoxMN7 QDo1VIg1say4MvcQowQHs5II77XpQCHelMTKqtSi/Pii0pzU4kOMpsBom8gsJZqcD0yVeSXx hsYGxoaGluYGpoZGFkrivP/P5YYICaQnlqRmp6YWpBbB9DFxcEo1MCYzrda78YH37C5TxWe2 SsK3+Q/Pe7j1eG1UqGZkj88+r/6tSxZIHTt6qbZqT63s4Zo5OQv2xgeIhZze9P34u0ZRydsW f9cFm90Te3XavKms22ThUYk1xRUSTc8TV3s8rQn0XfiLk5vZuUwvsOncuXk2bBN2qy503XO5 f1eb3L4pmv9W3RXxva/EUpyRaKjFXFScCAAm35TlXQMAAA== DLP-Filter: Pass X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t4RAcODR018728 On Tue 2015-05-27 16:50 (GMT+09:00), Pavel Machek wrote: >> So, instead of depending on a userspace task's time >> slice, let kworker do the work to avoid a long wait >> on the runqueue. > >...so if you really want high priority for that operation, just renice >yourself to higher priority or something... The problem occured on Android L version. KK had autosuspend enabled but it was disabled in L to allow userspace to collect stats. The delay was inside try_to_freeze_tasks function (at system_server thread of system_server process). system_server got preempted after unlocking the tasklist_lock. 46 while (true) { 47 todo = 0; 48 read_lock(&tasklist_lock); 49 for_each_process_thread(g, p) { 50 if (p == current || !freeze_task(p)) 51 continue; 52 53 if (!freezer_should_skip(p)) 54 todo++; 55 } 56 read_unlock(&tasklist_lock); All of the threads of system_server process that was on the runqueue did not run during this period. Freezing of tasks resumed after other tasks went out of the runqueue. I have tested with the lowest nice value but the problem was still, although less, reproducible. Best Regards, Euntaik Lee{.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I