Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp2474820ybp; Thu, 10 Oct 2019 07:56:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqzlSZ8t933+CD/oIMTuO6QHNy//miS8/A7KMjRbxSPGWzCHzcTRc68cqp4ZS1/R6wA6gEii X-Received: by 2002:aa7:d341:: with SMTP id m1mr8635559edr.57.1570719393453; Thu, 10 Oct 2019 07:56:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570719393; cv=none; d=google.com; s=arc-20160816; b=dUbsBo0Rd/PVnRleFMPklHOvLb+ryuMpjQB0+vJUGeIKeST1B2D9iZY7Tnn8zL67SC TiSqPRY9ybEcR/QO0ztZnFlhTjhOhmTkJoq8j/z3bsCSt/PmZjxeaaslbD4gRgBmRjE8 kByF2DB7o2g54liKXjSjsg4VXZEzn8VbnT49Ob2WhGBG/aNqgBlNGd//slkR3U3CqbJa PPtVf7XZTxjsV9cklJ54NPnlb6AHNqds8MWV1dAT8MyXUqoCe+/723hZRXt7CetnjdaY 4hdvYJFifFjeHmPOS/SnzsBCzZN1kFHzX7MlfPmMW9yqLmQpZ1Em19RSkEmluOqeY/cu /Lvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=011G/2lfqEY81qGFiuM4lHX/4MpFOrqZOEHviTCWDaQ=; b=Oj/k2FZt05VhOP+HlYg05kyBRURsOb6gn9BJfhkYzT81YTUE551tN95aE89tVU3R/C FyScvwBBvvyFyGadN+6Z3swBxmpYzru3xO+gMUr9JUy1jfQ/1jIywXPtafzEJb7TPEnz NAN2Z/Tkd08QQdLD/RAkVSzkLuB6nD22lwx3ZgmYMmKI0QmxacBnnkrXOqISXqw8MvXb n7uL0RV9pIAaiTZ0ZBhAyGOgAyhML/BjU07K1SeNh5L3WAvXJLOXqK6nQoIIQDDtv6W8 s+UM3shTgQQbsXgcI86cYh3PZ59qiTNlY8DxK8TRueNzdYQeeA/AeptYIPgGk8T0vmgK iSjw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w14si3317367edx.197.2019.10.10.07.56.10; Thu, 10 Oct 2019 07:56:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726599AbfJJOxZ (ORCPT + 99 others); Thu, 10 Oct 2019 10:53:25 -0400 Received: from foss.arm.com ([217.140.110.172]:32836 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726473AbfJJOxY (ORCPT ); Thu, 10 Oct 2019 10:53:24 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CD3971000; Thu, 10 Oct 2019 07:53:23 -0700 (PDT) Received: from [192.168.0.9] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B74B23F6C4; Thu, 10 Oct 2019 07:53:21 -0700 (PDT) Subject: Re: [RFC v5 4/6] sched/fair: Tune task wake-up logic to pack small background tasks on fewer cores To: Parth Shah , Vincent Guittot Cc: linux-kernel , "open list:THERMAL" , Peter Zijlstra , Ingo Molnar , Patrick Bellasi , Valentin Schneider , Pavel Machek , Doug Smythies , Quentin Perret , "Rafael J. Wysocki" , Tim Chen , Daniel Lezcano References: <20191007083051.4820-1-parth@linux.ibm.com> <20191007083051.4820-5-parth@linux.ibm.com> <80bb34ec-6358-f4dc-d20d-cde6c9d7e197@linux.ibm.com> <86dc25e4-9f19-627f-9581-d74608b7f20c@linux.ibm.com> <0ee8052e-e7fb-83cb-bf70-3c4855ccca8e@linux.ibm.com> From: Dietmar Eggemann Message-ID: <6a620fc4-daf9-dd02-7a81-3d9364bfe162@arm.com> Date: Thu, 10 Oct 2019 16:53:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <0ee8052e-e7fb-83cb-bf70-3c4855ccca8e@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/10/2019 19:02, Parth Shah wrote: > > > On 10/9/19 7:56 PM, Dietmar Eggemann wrote: >> On 09/10/2019 10:57, Parth Shah wrote: >> >> [...] >> >>>> On 07/10/2019 18:53, Parth Shah wrote: >>>>> >>>>> >>>>> On 10/7/19 5:49 PM, Vincent Guittot wrote: >>>>>> On Mon, 7 Oct 2019 at 10:31, Parth Shah wrote: [...] > ok. so does that mean TurboSched can still do some good in such systems as > well ? > I mean save energy even when rd->overutilized==1 by not waking user > classified bg tasks on idle core. I wouldn't say it is impossible but how likely would it be? The Android runtime already classifies its tasks into groups such as background, foreground, top-app, etc. It uses existing infrastructure like cpusets, taskgroups, util_clamp (or its out-of-tree predecessor schedtune) as well as EAS/Energy Model on asymmetric CPU capacity systems to map them (differently) onto the CPU topology to achieve the best possible performance/energy consumption trade-off. Moreover, Google and Arm are keen getting the concept of 'latency nice' upstream so we can map Android Common Kernel's 'prefer idle' feature into the mainline energy-aware wu path. So I'm afraid the question whether TurboSched could make sense on an Android system can only be answered by people responsible for future Android runtime architecture.