From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933212AbcA0Ooc (ORCPT <rfc822;w@1wt.eu>);
	Wed, 27 Jan 2016 09:44:32 -0500
Received: from bombadil.infradead.org ([198.137.202.9]:53234 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932497AbcA0Oo2 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 27 Jan 2016 09:44:28 -0500
Date: Wed, 27 Jan 2016 15:44:22 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: luca abeni <luca.abeni@unitn.it>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@arm.com>
Subject: Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth
Message-ID: <20160127144422.GS6357@twins.programming.kicks-ass.net>
References: <1452785094-3086-1-git-send-email-luca.abeni@unitn.it>
 <1452785094-3086-9-git-send-email-luca.abeni@unitn.it>
 <20160114195904.GH6357@twins.programming.kicks-ass.net>
 <5698ABFD.1040704@unitn.it>
 <20160115085004.GE3421@worktop>
 <20160126135219.338e8ccb@utopia>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160126135219.338e8ccb@utopia>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Jan 26, 2016 at 01:52:19PM +0100, luca abeni wrote:

> > The trouble is with interfaces. Once we expose them we're stuck with
> > them. And from that POV I think an explicit SCHED_OTHER server (or a
> > minimum budget for a slack time scheme) makes more sense.

> I am trying to work on this.
> Which kind of interface is better for this? Would adding something like
> /proc/sys/kernel/sched_other_period_us
> /proc/sys/kernel/sched_other_runtime_us
> be ok?
> 
> If this is ok, I'll add these two procfs files, and store
> (sched_other_runtime / sched_other_period) << 20 in the runqueue field
> which represents the unreclaimable utilization (implementing
> hierarchical SCHED_DEADLINE/CFS scheduling right now is too complex for
> this patchset... But if the exported interface is ok, it can be
> implemented later).
> 
> Is this approach acceptable? Or am I misunderstanding your comment?

No, I think that's fine.

Altough now you have me worrying about per root_domain settings and the
like. But I think we can do that with additional interfaces, if needed.

So yes, please go with that.

And agreed, a full CFS server is a bit outside scope for this patch-set.