Hey,
Op 10-03-15 om 16:28 schreef Peter Zijlstra:
> On Tue, Mar 10, 2015 at 03:10:46PM +0100, Maarten Lankhorst wrote:
>> Op 10-03-15 om 13:37 schreef Peter Zijlstra:
>
>>> So IIRC this is the function that checks who gets wounded (and gets to
>>> do the whole retry thing), right?
>>>
>>> So for
On Tue, Mar 10, 2015 at 03:10:46PM +0100, Maarten Lankhorst wrote:
> Op 10-03-15 om 13:37 schreef Peter Zijlstra:
> > So IIRC this is the function that checks who gets wounded (and gets to
> > do the whole retry thing), right?
> >
> > So for the RT case, I think we should extend it to not (primari
Op 10-03-15 om 13:37 schreef Peter Zijlstra:
> On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote:
>> +static int __sched __mutex_lock_check_stamp(struct rt_mutex *lock,
>> +struct ww_acquire_ctx *ctx)
>> +{
>> +#ifdef CONFIG_WW_MUTEX_R
On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote:
> +static int __sched __mutex_lock_check_stamp(struct rt_mutex *lock,
> + struct ww_acquire_ctx *ctx)
On that; should we rename this to __ww_mutex_check_wound() ? or
something to more
On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote:
> +#ifdef CONFIG_WW_MUTEX_RTMUTEX
> +static void ww_mutex_lock_acquired(struct ww_mutex *ww,
> +struct ww_acquire_ctx *ww_ctx)
> +{
> +#ifdef CONFIG_DEBUG_MUTEXES
> + /*
> + * If this
On Tue, Mar 10, 2015 at 01:37:40PM +0100, Peter Zijlstra wrote:
> On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote:
> > +static int __sched __mutex_lock_check_stamp(struct rt_mutex *lock,
> > + struct ww_acquire_ctx *ctx)
> > +{
> > +#i
On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote:
> +static int __sched __mutex_lock_check_stamp(struct rt_mutex *lock,
> + struct ww_acquire_ctx *ctx)
> +{
> +#ifdef CONFIG_WW_MUTEX_RTMUTEX
> + struct ww_mutex *ww = container_of(
On Fri, Feb 27, 2015 at 05:57:08PM +0100, Sebastian Andrzej Siewior wrote:
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index 16b2d3cc88b0..0a652ba46081 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -106,6 +106,7 @@ void __sched mutex_lock(struct mute
On Mon, Mar 09, 2015 at 02:21:53PM +0100, Sebastian Andrzej Siewior wrote:
> On 03/09/2015 12:29 PM, Mike Galbraith wrote:
> > On Mon, 2015-03-09 at 12:07 +0100, Sebastian Andrzej Siewior wrote:
> >> On 03/09/2015 11:51 AM, Mike Galbraith wrote:
> >>> Why do both mutex and rtmutex then exist one mi
On 03/09/2015 12:29 PM, Mike Galbraith wrote:
> On Mon, 2015-03-09 at 12:07 +0100, Sebastian Andrzej Siewior wrote:
>> On 03/09/2015 11:51 AM, Mike Galbraith wrote:
>>> Why do both mutex and rtmutex then exist one might ask? ;-) No big deal
>>> either way though, it's not like it becomes immutable
On Mon, 2015-03-09 at 12:07 +0100, Sebastian Andrzej Siewior wrote:
> On 03/09/2015 11:51 AM, Mike Galbraith wrote:
> > 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.
>
> You don't choose rtmutex afai
On 03/09/2015 11:51 AM, Mike Galbraith wrote:
> 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.
You don't choose rtmutex afaik. rtmutex is used by futex (only?) and
one of the things it does is PI.
On -R
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 onl
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:
[ ]
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 prefer
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 do
On 06-03-15 13:14, Sebastian Andrzej Siewior wrote:
> On 03/02/2015 09:46 AM, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 02-03-15 om 04:20 schreef Mike Galbraith:
>>> On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
This patch makes it possible to replace the base mutex by
On 03/02/2015 09:46 AM, Maarten Lankhorst wrote:
> Hey,
>
> Op 02-03-15 om 04:20 schreef Mike Galbraith:
>> On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
>>> This patch makes it possible to replace the base mutex by a rt_mutex. In
>>> general one would not do this.
>> I would
On Mon, 2015-03-02 at 09:46 +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 02-03-15 om 04:20 schreef Mike Galbraith:
> > On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
> >> This patch makes it possible to replace the base mutex by a rt_mutex. In
> >> general one would not do th
Hey,
Op 02-03-15 om 04:20 schreef Mike Galbraith:
> On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
>> This patch makes it possible to replace the base mutex by a rt_mutex. In
>> general one would not do this.
> I would argue that the thing should be born as a full fledged prim
On Fri, 2015-02-27 at 17:57 +0100, Sebastian Andrzej Siewior wrote:
> This patch makes it possible to replace the base mutex by a rt_mutex. In
> general one would not do this.
I would argue that the thing should be born as a full fledged primitive,
not a config option, as an rt_ww_mutex is the ww
This patch makes it possible to replace the base mutex by a rt_mutex. In
general one would not do this. In -RT we use rt_mutex instead of the
mutex by default and this means we need the ww_mutex functionality based
on rt_mutex.
This patch includes a slightly modified version of what we have in the
22 matches
Mail list logo
