Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp798374imm; Wed, 10 Oct 2018 04:36:24 -0700 (PDT) X-Google-Smtp-Source: ACcGV60jIxbTazGL3VpBbQd6/kERerLnKCuTTWZq2Wr5GogNaMcO35Hnodt6AMcKX0JgQXSuhh9f X-Received: by 2002:a63:e442:: with SMTP id i2-v6mr12693480pgk.381.1539171384093; Wed, 10 Oct 2018 04:36:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539171384; cv=none; d=google.com; s=arc-20160816; b=O1g7FrK1inRwsNu2Wk7AwFojPt4jlT0ZuXgrKqDGCG8r5Eya5SVlTmF43KmzgRzxLj 7xMBKqHrK/SxLRWgGKsncl1VrPVvbAmGxvFoE5Y0Jvm05KfaIYj2xs7PzzrOFQkgFMxh 9fdAU39qoJQtbSvfZMkWiQFED2/OSPOIG72AOtofwXWHjYGWk6lnCzKI2X4w5wP3WudJ EmxNntmfsy8cIHd6del0EHcxnv+qVkNGvngxYSbTNU1iwWbf/kI1xiNcvv5KAsQZqC7I NPH2T8oUvw9R/SfeRrbeCuG3lH3cDt6X6b8nNL/eV8l3kIis1pXA/I2fE1vRK8doz1ap K0UQ== 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:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=mc7kj3oGodGpc7PsFTZYcw51sdIc6hd3E+ktSjkcTvI=; b=UaQ1nKo+vtEjYVQCkViT0+KZeGC85oghpO6bf8t29BxiG+IJBp1U1y0AnAewYXs1n+ pPzzjGQR67pcO9jRosTjkHm3IPMOPu3NT3yyAM2SHVsUUs28gsbfU+fAe6q123t/ML5a z0uZ1bDbWcZVa5OEejo1CwbVibNAhG8yFgPedfQMNnnMam7jCQWcVhd82G4Ij4NT9+lj dOCBVt0L8IQz39NettirRWXBorb7nDrHvNFwCbFp7VWxRE3m2olWMpuSF6IrfhAeoj3d akoKQ1OP/kI7vN711HB38XNfRijdfljxT5CvPLPtYXwOoxucMnbzq3Q2seWR05UckOPy ia6Q== 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 w2-v6si24355386pll.171.2018.10.10.04.36.08; Wed, 10 Oct 2018 04:36:24 -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 S1726893AbeJJS4M (ORCPT + 99 others); Wed, 10 Oct 2018 14:56:12 -0400 Received: from mail.santannapisa.it ([193.205.80.99]:33731 "EHLO mail.santannapisa.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726022AbeJJS4L (ORCPT ); Wed, 10 Oct 2018 14:56:11 -0400 Received: from [10.30.3.207] (account l.abeni@santannapisa.it HELO luca64) by santannapisa.it (CommuniGate Pro SMTP 6.1.11) with ESMTPSA id 133568996; Wed, 10 Oct 2018 12:34:24 +0200 Date: Wed, 10 Oct 2018 12:34:17 +0200 From: luca abeni To: Juri Lelli Cc: peterz@infradead.org, mingo@redhat.com, rostedt@goodmis.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, 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, henrik@austad.us, linux-rt-users@vger.kernel.org Subject: Re: [RFD/RFC PATCH 0/8] Towards implementing proxy execution Message-ID: <20181010123417.26c682ef@luca64> In-Reply-To: <20181009092434.26221-1-juri.lelli@redhat.com> References: <20181009092434.26221-1-juri.lelli@redhat.com> Organization: Scuola Superiore S. Anna X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, On Tue, 9 Oct 2018 11:24:26 +0200 Juri Lelli wrote: > Hi all, > > 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). > > 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). First of all, thanks to Juri for working on this! I am looking at the patchset, and I have some questions / comments (maybe some of my questions are really stupid, I do not know... :) To begin, I have a very high-level comment about proxy execution: I believe proxy execution is a very powerful concept, that can be used in many cases, not only to do inheritance on mutual exclusion (think, for example, about pipelines of tasks: a task implementing a stage of the pipeline can act as a proxy for the task implementing the previous stage). So, I would propose to make the proxy() function of patch more generic, and not strictly bound to mutexes. Maybe a task structure can contain a list of tasks for which the task can act as a proxy, and we can have a function like "I want to act as a proxy for task T" to be invoked when a task blocks? Luca