From: Juri Lelli <juri.lelli@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: 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,
henrik@austad.us, linux-rt-users@vger.kernel.org
Subject: Re: [RFD/RFC PATCH 0/8] Towards implementing proxy execution
Date: Tue, 9 Oct 2018 11:58:35 +0200 [thread overview]
Message-ID: <20181009095835.GE9130@localhost.localdomain> (raw)
In-Reply-To: <20181009094441.GI5663@hirez.programming.kicks-ass.net>
On 09/10/18 11:44, Peter Zijlstra wrote:
> On Tue, Oct 09, 2018 at 11:24:26AM +0200, Juri Lelli wrote:
> > The main concerns I have with the current approach is that, being based
> > on mutex.c, it's both
> >
> > - not linked with futexes
> > - not involving "legacy" priority inheritance (rt_mutex.c)
> >
> > I believe one of the main reasons Peter started this on mutexes is to
> > have better coverage of potential problems (which I can assure everybody
> > it had). I'm not yet sure what should we do moving forward, and this is
> > exactly what I'd be pleased to hear your opinions on.
>
> Well that, and mutex was 'simple', I didn't have to go rip out all the
> legacy PI crud.
Indeed.
> If this all ends up working well, the solution is 'simple' and we can
> simply copy mutex to rt_mutex or something along those lines if we want
> to keep the distinction between them. Alternatively we simply delete
> rt_mutex.
Ah.. right.. sounds *scary*, but I guess it might be an option after
all.
> Thanks for reviving this.. it's been an 'interesting' year and a half
> since I wrote all this and I've really not had time to work on it.
n/p, it has been a long standing thing to look at for me as well. Thanks
again for sharing your patches!
next prev parent reply other threads:[~2018-10-09 9:58 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 [this message]
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
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=20181009095835.GE9130@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.