From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41A0DC3A5A5 for ; Thu, 5 Sep 2019 13:32:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 87C0C2070C for ; Thu, 5 Sep 2019 13:32:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727213AbfIENcH (ORCPT ); Thu, 5 Sep 2019 09:32:07 -0400 Received: from foss.arm.com ([217.140.110.172]:45264 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726097AbfIENcG (ORCPT ); Thu, 5 Sep 2019 09:32:06 -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 5317328; Thu, 5 Sep 2019 06:32:05 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 86B203F67D; Thu, 5 Sep 2019 06:32:03 -0700 (PDT) Date: Thu, 5 Sep 2019 14:32:01 +0100 From: Qais Yousef To: Peter Zijlstra Cc: Patrick Bellasi , Subhra Mazumdar , linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de, steven.sistare@oracle.com, dhaval.giani@oracle.com, daniel.lezcano@linaro.org, vincent.guittot@linaro.org, viresh.kumar@linaro.org, tim.c.chen@linux.intel.com, mgorman@techsingularity.net, parth@linux.ibm.com Subject: Re: [RFC PATCH 1/9] sched,cgroup: Add interface for latency-nice Message-ID: <20190905133200.4w4cupgxgeym3l2k@e107158-lin.cambridge.arm.com> References: <20190830174944.21741-1-subhra.mazumdar@oracle.com> <20190830174944.21741-2-subhra.mazumdar@oracle.com> <20190905083127.GA2332@hirez.programming.kicks-ass.net> <87r24v2i14.fsf@arm.com> <20190905104616.GD2332@hirez.programming.kicks-ass.net> <20190905111346.2w6kuqrdvaqvgilu@e107158-lin.cambridge.arm.com> <20190905113002.GK2349@hirez.programming.kicks-ass.net> <87ftlb2cq6.fsf@arm.com> <20190905114802.GN2349@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190905114802.GN2349@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/05/19 13:48, Peter Zijlstra wrote: > On Thu, Sep 05, 2019 at 12:40:01PM +0100, Patrick Bellasi wrote: > > Right, although I think behaviours could still be exported but via a > > different and configurable interface, using thresholds. > > I would try _really_ hard to avoid pinning down behaviour. The more you > do that, the less you can change. While I agree with that but I find there's a contradiction between not 'pinning down behavior' and 'easy and clear way to bias latency sensitive from end user's perspective'. Maybe we should protect this with a kconfig + experimental tag until trial and error show the best way forward? -- Qais Yousef