Hi all, On Tue, 9 Oct 2018 11:24:26 +0200 Juri Lelli <juri.lelli@xxxxxxxxxx> 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
