From: Juri Lelli <juri.lelli@redhat.com>
To: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
peterz@infradead.org, 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,
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 14:35:58 +0200 [thread overview]
Message-ID: <20181009123558.GF9130@localhost.localdomain> (raw)
In-Reply-To: <9837aa4b-1bd4-bc6a-84f7-0b8704995d44@redhat.com>
On 09/10/18 13:56, Daniel Bristot de Oliveira wrote:
> On 10/9/18 12:51 PM, Sebastian Andrzej Siewior 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.
> > wasn't the idea that once it works to get rid of rt_mutex?
Looks like it was (see Peter's reply).
> As far as I know, it is. But there are some additional complexity
> involving a -rt version of this patch, for instance:
>
> What should the protocol do if the thread migrating is with migration
> disabled?
>
> The side effects of, for instance, ignoring the migrate_disable() would
> add noise for the initial implementation... too much complexity at once.
>
> IMHO, once it works in the non-rt, it will be easier to do the changes
> needed to integrate it with -rt.
>
> Thoughts?
Makes sense to me. Maybe we should just still keep in mind eventual
integration, so that we don't take decisions we would regret.
next prev parent reply other threads:[~2018-10-09 12:35 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 [this message]
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=20181009123558.GF9130@localhost.localdomain \
--to=juri.lelli@redhat.com \
--cc=alessio.balsini@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=bigeasy@linutronix.de \
--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.