From: luca abeni <luca.abeni@santannapisa.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Juri Lelli <juri.lelli@redhat.com>,
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
Date: Wed, 10 Oct 2018 13:16:29 +0200 [thread overview]
Message-ID: <20181010131629.6623ddb4@luca64> (raw)
In-Reply-To: <20181010105710.GP5728@hirez.programming.kicks-ass.net>
On Wed, 10 Oct 2018 12:57:10 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Oct 10, 2018 at 12:34:17PM +0200, luca abeni wrote:
> > 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?
>
> Certainly possible, but that's something I'd prefer to look at after
> it all 'works'.
Of course :)
I was mentioning this idea because maybe it can have some impact on the
design.
BTW, here is another "interesting" issue I had in the past with changes
like this one: how do we check if the patchset works as expected?
"No crashes" is surely a requirement, but I think we also need some
kind of testcase that fails if the inheritance mechanism is not working
properly, and is successful if the inheritance works.
Maybe we can develop some testcase based on rt-app (if noone has such a
testcase already)
Thanks,
Luca
> The mutex blocking thing doesn't require external
> interfaces etc..
next prev parent reply other threads:[~2018-10-10 11:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-09 9:24 [RFD/RFC PATCH 0/8] Towards implementing proxy execution Juri Lelli
2018-10-09 9:24 ` [RFD/RFC PATCH 1/8] locking/mutex: Convert mutex::wait_lock to raw_spinlock_t Juri Lelli
2018-10-09 9:24 ` [RFD/RFC PATCH 2/8] locking/mutex: Removes wakeups from under mutex::wait_lock Juri Lelli
2018-10-09 9:24 ` [RFD/RFC PATCH 3/8] locking/mutex: Rework task_struct::blocked_on Juri Lelli
2018-10-10 10:43 ` luca abeni
2018-10-10 11:06 ` Juri Lelli
2018-10-09 9:24 ` [RFD/RFC PATCH 4/8] sched: Split scheduler execution context Juri Lelli
2019-05-06 11:06 ` Claudio Scordino
2018-10-09 9:24 ` [RFD/RFC PATCH 5/8] sched: Add proxy execution Juri Lelli
2018-10-10 11:10 ` luca abeni
2018-10-11 12:34 ` Juri Lelli
2018-10-11 12:53 ` Peter Zijlstra
2018-10-11 13:42 ` Juri Lelli
2018-10-12 7:22 ` luca abeni
2018-10-12 8:30 ` Juri Lelli
2018-10-09 9:24 ` [RFD/RFC PATCH 6/8] locking/mutex: make mutex::wait_lock irq safe Juri Lelli
2018-10-09 9:24 ` [RFD/RFC PATCH 7/8] sched: Ensure blocked_on is always guarded by blocked_lock Juri Lelli
2018-10-09 9:24 ` [RFD/RFC PATCH 8/8] sched: Fixup task CPUs for potential proxies Juri Lelli
2018-10-09 9:44 ` [RFD/RFC PATCH 0/8] Towards implementing proxy execution Peter Zijlstra
2018-10-09 9:58 ` Juri Lelli
2018-10-09 10:51 ` Sebastian Andrzej Siewior
2018-10-09 11:56 ` Daniel Bristot de Oliveira
2018-10-09 12:35 ` Juri Lelli
2018-10-10 10:34 ` luca abeni
2018-10-10 10:57 ` Peter Zijlstra
2018-10-10 11:16 ` luca abeni [this message]
2018-10-10 11:23 ` Peter Zijlstra
2018-10-10 12:27 ` Juri Lelli
2018-10-10 11:56 ` Henrik Austad
2018-10-10 12:24 ` Peter Zijlstra
2018-10-10 13:48 ` Daniel Bristot de Oliveira
2018-10-10 12:36 ` Juri Lelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181010131629.6623ddb4@luca64 \
--to=luca.abeni@santannapisa.it \
--cc=alessio.balsini@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=bristot@redhat.com \
--cc=claudio@evidence.eu.com \
--cc=dietmar.eggemann@arm.com \
--cc=henrik@austad.us \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tommaso.cucinotta@santannapisa.it \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).