All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <umgwanakikbuti@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>,
	linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock
Date: Mon, 09 Mar 2015 11:51:04 +0100	[thread overview]
Message-ID: <1425898264.9329.10.camel@gmail.com> (raw)
In-Reply-To: <54FD6F5A.1030809@linutronix.de>

On Mon, 2015-03-09 at 11:00 +0100, Sebastian Andrzej Siewior wrote:
> On 03/06/2015 06:50 PM, Mike Galbraith wrote:
> > On Fri, 2015-03-06 at 13:36 +0100, Sebastian Andrzej Siewior wrote:
> >> On 03/06/2015 01:16 PM, Maarten Lankhorst wrote:
> >>
> >>>> Okay so what I the point made here? It is only about the config option,
> >>>> right? What are the preferences here:
> >>>> [ ] yes, the way it is now
> >>> Is my personal preference, but I'm not a locking expert(TM).
> >>
> >> Lets see what Mike says. I currently don't see any reason for people to
> >> switch between both implementations except for testing. And if it
> >> remains hidden then nobody changing code ww_mutex tests against
> >> rt_mutex. That way there is hope :)
> > 
> > I don't see much point in an all or nothing config option, it'll just
> 
> it could be used for testing. My hope here is that if someone changes
> something within ww_mutex they test it ob both implementations.
> 
> > sit idle.  If folks can use them where they see fit, they might just do
> > that.  We have mutex/rtmutex, so why not ww_mutex/rt_ww_mutex?  Looks
> > like a natural extension to me.
> 
> And why would they need it? I would assume that this would only confuse
> them. And if (for $reason) they need PI they will (most likely) need it
> for everything not just one lock.

Why do both mutex and rtmutex then exist one might ask? ;-)  No big deal
either way though, it's not like it becomes immutable once applied.

	-Mike


  reply	other threads:[~2015-03-09 10:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-27 16:57 rt_mutex based ww_mutex implementation Sebastian Andrzej Siewior
2015-02-27 16:57 ` [PATCH 1/3] locking: ww_mutex: add one level of indirection for access of the lock Sebastian Andrzej Siewior
2015-02-27 18:20   ` Maarten Lankhorst
2015-02-27 18:57     ` Sebastian Andrzej Siewior
2015-02-27 16:57 ` [PATCH 2/3] locking: ww_mutex: Allow to use rt_mutex instead of mutex for the baselock Sebastian Andrzej Siewior
2015-03-02  3:20   ` Mike Galbraith
2015-03-02  8:46     ` Maarten Lankhorst
2015-03-02 12:50       ` Mike Galbraith
2015-03-06 12:14       ` Sebastian Andrzej Siewior
2015-03-06 12:16         ` Maarten Lankhorst
2015-03-06 12:36           ` Sebastian Andrzej Siewior
2015-03-06 17:50             ` Mike Galbraith
2015-03-09 10:00               ` Sebastian Andrzej Siewior
2015-03-09 10:51                 ` Mike Galbraith [this message]
2015-03-09 11:07                   ` Sebastian Andrzej Siewior
2015-03-09 11:29                     ` Mike Galbraith
2015-03-09 13:21                       ` Sebastian Andrzej Siewior
2015-03-09 22:27                         ` Paul E. McKenney
2015-03-10 12:30   ` Peter Zijlstra
2015-03-10 12:37   ` Peter Zijlstra
2015-03-10 12:39     ` Peter Zijlstra
2015-03-10 14:10     ` Maarten Lankhorst
2015-03-10 15:28       ` Peter Zijlstra
2015-03-10 18:21         ` Maarten Lankhorst
2015-03-10 12:43   ` Peter Zijlstra
2015-03-10 12:46   ` Peter Zijlstra
2015-02-27 16:57 ` [PATCH 3/3] locking: rtmutex: set state back to running on error Sebastian Andrzej Siewior
2015-02-28 10:00   ` [tip:locking/urgent] locking/rtmutex: Set " tip-bot for Sebastian Andrzej Siewior
2015-03-01  5:35   ` [PATCH 3/3] locking: rtmutex: set " Mike Galbraith
2015-03-01  8:48   ` [tip:locking/urgent] locking/rtmutex: Set " tip-bot for Sebastian Andrzej Siewior

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=1425898264.9329.10.camel@gmail.com \
    --to=umgwanakikbuti@gmail.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@canonical.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /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.