From: Juri Lelli <juri.lelli@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: luca abeni <luca.abeni@santannapisa.it>,
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 14:27:42 +0200 [thread overview]
Message-ID: <20181010122742.GM9130@localhost.localdomain> (raw)
In-Reply-To: <20181010112300.GQ5728@hirez.programming.kicks-ass.net>
On 10/10/18 13:23, Peter Zijlstra wrote:
> On Wed, Oct 10, 2018 at 01:16:29PM +0200, luca abeni wrote:
> > 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)
>
> Indeed; IIRC there is a test suite that mostly covers the FIFO-PI stuff,
> that should obviously still pass. Steve, do you know where that lives?
>
> For the extended DL stuff, we'd need new tests.
This one, right?
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/tree/src/pi_tests/pi_stress.c?h=stable/v1.0
It looks like it supports DEADLINE as well.. although I'll have to check
again what it does for the DEADLINE case.
next prev parent reply other threads:[~2018-10-10 12:27 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
2018-10-10 11:23 ` Peter Zijlstra
2018-10-10 12:27 ` Juri Lelli [this message]
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=20181010122742.GM9130@localhost.localdomain \
--to=juri.lelli@redhat.com \
--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=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=luca.abeni@santannapisa.it \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.