Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp851922imm; Wed, 10 Oct 2018 05:27:01 -0700 (PDT) X-Google-Smtp-Source: ACcGV63TlqTg1kScVHVcZ2hBlxZnBFTWEPakMGshBmBqZHtYZzYTYnA2jCqCSfBGNPbaPSTGpDD8 X-Received: by 2002:a62:ea03:: with SMTP id t3-v6mr35817352pfh.228.1539174421222; Wed, 10 Oct 2018 05:27:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539174421; cv=none; d=google.com; s=arc-20160816; b=LSNOZq9CCgAHUJQPDKvwdzjp5API39A2I+L7ZA8XvuMikdY0WRf/Vptfi+KtgZ5SHs jVzor3bL/RsaLR8liya/CLJaI/th/Ze3LAMdwdQiAO3XpYal7MUDh5jF7iplqJZfZMA5 3SJgJlVO9FTbKql1IZlxVgWcqWKvE+iUF/tYYd+tyt4Gu92191+QEjX5VEYUG2l4Wwzf /D1zblkwUzH59y+uzYXQwWmGN5+2thWpMnZNQfBKE3PFCl9lMNHfC0qEI/ANCTKouC9a Ylj1MwVePeE1B8ImrFyFKJ06l1+cA2dUh8+TgchDjEp5UBWFZlnvMsFpfRlUgLqRDCVG 8tDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=l5HgXudRo/pDiprhmaIgNFDr6UzvKOBYblCMU6cOosY=; b=UAS4jdymQiNSTCTeYUNdGgRMAjmqZyyQxhYjY48wgriPU5OlRAOgWMz34Np1N0NPiV QNMe43dXnI4IJzrRyh6xMKASLe/DSpMje0e3Mu/IM6KY4ak500MDkVp+yBjtcx/bTya/ ahATOjHLH1gOopWY6wJkd+9AwG/8LLnitopRA7otEoQrvoXuqbMTlnbzXjsmRQCMpnQS 0ZM4Kicd7HYT8y8Cbr8cooHXwzw+VabOUWZedY9WxV7NY4ektg5H+BgN3SfTf9ZoAuhX CocJohihkuSOi33R0Tcjf2hjtIJKl5GE1N7iKeEKQ4lQMl6SP+B7waSX4ulmIZUkl4tm ZSTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=brEKFMPm; 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 r6-v6si27693482pfc.253.2018.10.10.05.26.45; Wed, 10 Oct 2018 05:27:01 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=brEKFMPm; 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 S1726689AbeJJTrC (ORCPT + 99 others); Wed, 10 Oct 2018 15:47:02 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:38918 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726206AbeJJTrB (ORCPT ); Wed, 10 Oct 2018 15:47:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l5HgXudRo/pDiprhmaIgNFDr6UzvKOBYblCMU6cOosY=; b=brEKFMPmZP2NvBIADEaT21Ke/G giCaxdL0kwzbU1j1k+Y30CD+s0d7mRIMtaf6oa+swYFVKsOWh8zEwg2nJdgyvFj5XJeupbtZiXWLE YoO72vgGg6dBEAbnMBu71vyNpRPRfFxinc9YLY/kTmRu4kWuv3nmVW4KOmunxgvjUJERJ7Pf6PZ3U 3j4adsj78eUqBN+sHSOjWcQzZ57Qoh11s1H89F+N9kv1zEX55BiBLUGQa1LgDd566H9aw17m+Dt7V x8hEIH9fhc08V9qW5P1Li7lo7363/ZSCobxhugf3e0NR6u4IOlD3tVYHPaHzon497i0mP1QA5GpUG WbecOJbA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1gADXs-0000dS-Nn; Wed, 10 Oct 2018 12:24:56 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 8C2C22029856A; Wed, 10 Oct 2018 14:24:54 +0200 (CEST) Date: Wed, 10 Oct 2018 14:24:54 +0200 From: Peter Zijlstra To: Henrik Austad Cc: Juri Lelli , mingo@redhat.com, rostedt@goodmis.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, luca.abeni@santannapisa.it, claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it, alessio.balsini@gmail.com, bristot@redhat.com, will.deacon@arm.com, andrea.parri@amarulasolutions.com, dietmar.eggemann@arm.com, patrick.bellasi@arm.com, linux-rt-users@vger.kernel.org Subject: Re: [RFD/RFC PATCH 0/8] Towards implementing proxy execution Message-ID: <20181010122454.GR5663@hirez.programming.kicks-ass.net> References: <20181009092434.26221-1-juri.lelli@redhat.com> <20181010115639.GA25534@sisyphus.home.austad.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20181010115639.GA25534@sisyphus.home.austad.us> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 10, 2018 at 01:56:39PM +0200, Henrik Austad wrote: > On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote: > > Hi all, >=20 > Hi, nice series, I have a lot of details to grok, but I like the idea of = PE >=20 > > Proxy Execution (also goes under several other names) isn't a new > > concept, it has been mentioned already in the past to this community > > (both in email discussions and at conferences [1, 2]), but no actual > > implementation that applies to a fairly recent kernel exists as of today > > (of which I'm aware of at least - happy to be proven wrong). > >=20 > > Very broadly speaking, more info below, proxy execution enables a task > > to run using the context of some other task that is "willing" to > > participate in the mechanism, as this helps both tasks to improve > > performance (w.r.t. the latter task not participating to proxy > > execution). >=20 > From what I remember, PEP was originally proposed for a global EDF, and a= s=20 > far as my head has been able to read this series, this implementation is= =20 > planned for not only deadline, but eventuall also for sched_(rr|fifo|othe= r)=20 > - is that correct? This implementation covers every scheduling class unconditionally. It directly uses the scheduling function to order things; where PI re-implements the FIFO scheduling function to order the blocked lists. > I have a bit of concern when it comes to affinities and and where the=20 > lock owner will actually execute while in the context of the proxy,=20 > especially when you run into the situation where you have disjoint CPU=20 > affinities for _rr tasks to ensure the deadlines. The affinities of execution contexts are respected. > I believe there were some papers circulated last year that looked at=20 > something similar to this when you had overlapping or completely disjoint= =20 > CPUsets I think it would be nice to drag into the discussion. Has this be= en=20 > considered? (if so, sorry for adding line-noise!) Hurm, was that one of Bjorn's papers? Didn't that deal with AC of disjoint/overlapping sets? > > One can define the scheduling context of a task as all the information > > in task_struct that the scheduler needs to implement a policy and the > > execution contex as all the state required to actually "run" the task. > > An example of scheduling context might be the information contained in > > task_struct se, rt and dl fields; affinity pertains instead to execution > > context (and I guess decideing what pertains to what is actually up for > > discussion as well ;-). Patch 04/08 implements such distinction. >=20 > I really like the idea of splitting scheduling ctx and execution context! Right; so this whole thing relies on 'violating' affinities for scheduling contexts, but respects affinities for execution contexts. The basic observation is that affinities only matter when you execute code. This then also gives a fairly clear definition of what an execution context is.