On Mon, May 27, 2013 at 4:47 PM, Daniel Vetter wrote:
> On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra
> wrote:
>> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
>>> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
>>> >> + stru
On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra
wrote:
> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
>> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
>> >> + struct ww_class *ww_class)
>> >> +{
>> >> + ctx->task = current;
Op 27-05-13 13:15, Peter Zijlstra schreef:
> On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote:
>> The reason ttm needed it was because there was another lock that interacted
>> with the ctx lock in a weird way. The ww lock it was using was inverted with
>> another
>> lock, so it h
On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote:
> The reason ttm needed it was because there was another lock that interacted
> with the ctx lock in a weird way. The ww lock it was using was inverted with
> another
> lock, so it had to grab that lock first, perform a trylock on
Op 27-05-13 12:24, Peter Zijlstra schreef:
> On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote:
>>> Again, early.. monday.. would a trylock, even if successful still need
>>> the ctx?
>> No ctx for trylock is supported. You can still do a trylock while
>> holding a context, but the
On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote:
> > Again, early.. monday.. would a trylock, even if successful still need
> > the ctx?
> No ctx for trylock is supported. You can still do a trylock while
> holding a context, but the mutex won't be a part of the context.
> Normal
Op 27-05-13 10:21, Peter Zijlstra schreef:
> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
+static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
+ struct ww_class *ww_class)
+{
+ ctx->task = current;
+ do {
+
Op 27-05-13 11:13, Peter Zijlstra schreef:
> On Mon, May 27, 2013 at 10:26:39AM +0200, Maarten Lankhorst wrote:
>> Op 27-05-13 10:00, Peter Zijlstra schreef:
>>> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
>> +- Functions to only acquire a single w/w mutex, which results
On Mon, May 27, 2013 at 10:26:39AM +0200, Maarten Lankhorst wrote:
> Op 27-05-13 10:00, Peter Zijlstra schreef:
> > On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> +- Functions to only acquire a single w/w mutex, which results in the
> exact same
> + semantics
On Wed, May 22, 2013 at 06:49:04PM +0200, Daniel Vetter wrote:
> - _slow functions can check whether all acquire locks have been
> released and whether the caller is indeed blocking on the contending
> lock. Not doing so could either result in needless spinning instead of
> blocking (when blocking
Op 27-05-13 10:00, Peter Zijlstra schreef:
> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
+- Functions to only acquire a single w/w mutex, which results in the
exact same
+ semantics as a normal mutex. These functions have the _single postfix.
>>> This is miss
On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
> >> + struct ww_class *ww_class)
> >> +{
> >> + ctx->task = current;
> >> + do {
> >> + ctx->stamp = atomic_long_inc_return
On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> >> +- Functions to only acquire a single w/w mutex, which results in the
> >> exact same
> >> + semantics as a normal mutex. These functions have the _single postfix.
> > This is missing rationale.
> trylock_single is useful wh
On Mon, May 27, 2013 at 4:47 PM, Daniel Vetter wrote:
> On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra wrote:
>> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
>>> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
>>> >> + struct
On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra wrote:
> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
>> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
>> >> + struct ww_class *ww_class)
>> >> +{
>> >> + ctx->task = current;
>
Op 27-05-13 13:15, Peter Zijlstra schreef:
> On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote:
>> The reason ttm needed it was because there was another lock that interacted
>> with the ctx lock in a weird way. The ww lock it was using was inverted with
>> another
>> lock, so it h
On Mon, May 27, 2013 at 12:52:00PM +0200, Maarten Lankhorst wrote:
> The reason ttm needed it was because there was another lock that interacted
> with the ctx lock in a weird way. The ww lock it was using was inverted with
> another
> lock, so it had to grab that lock first, perform a trylock on
Op 27-05-13 12:24, Peter Zijlstra schreef:
> On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote:
>>> Again, early.. monday.. would a trylock, even if successful still need
>>> the ctx?
>> No ctx for trylock is supported. You can still do a trylock while
>> holding a context, but the
On Mon, May 27, 2013 at 12:01:50PM +0200, Maarten Lankhorst wrote:
> > Again, early.. monday.. would a trylock, even if successful still need
> > the ctx?
> No ctx for trylock is supported. You can still do a trylock while
> holding a context, but the mutex won't be a part of the context.
> Normal
Op 27-05-13 10:21, Peter Zijlstra schreef:
> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
+static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
+ struct ww_class *ww_class)
+{
+ ctx->task = current;
+ do {
+
Op 27-05-13 11:13, Peter Zijlstra schreef:
> On Mon, May 27, 2013 at 10:26:39AM +0200, Maarten Lankhorst wrote:
>> Op 27-05-13 10:00, Peter Zijlstra schreef:
>>> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
>> +- Functions to only acquire a single w/w mutex, which results
On Mon, May 27, 2013 at 10:26:39AM +0200, Maarten Lankhorst wrote:
> Op 27-05-13 10:00, Peter Zijlstra schreef:
> > On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> +- Functions to only acquire a single w/w mutex, which results in the
> exact same
> + semantics
On Wed, May 22, 2013 at 06:49:04PM +0200, Daniel Vetter wrote:
> - _slow functions can check whether all acquire locks have been
> released and whether the caller is indeed blocking on the contending
> lock. Not doing so could either result in needless spinning instead of
> blocking (when blocking
Op 27-05-13 10:00, Peter Zijlstra schreef:
> On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
+- Functions to only acquire a single w/w mutex, which results in the
exact same
+ semantics as a normal mutex. These functions have the _single postfix.
>>> This is miss
On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> >> +static inline void ww_acquire_init(struct ww_acquire_ctx *ctx,
> >> + struct ww_class *ww_class)
> >> +{
> >> + ctx->task = current;
> >> + do {
> >> + ctx->stamp = atomic_long_inc_return
On Wed, May 22, 2013 at 07:24:38PM +0200, Maarten Lankhorst wrote:
> >> +- Functions to only acquire a single w/w mutex, which results in the
> >> exact same
> >> + semantics as a normal mutex. These functions have the _single postfix.
> > This is missing rationale.
> trylock_single is useful wh
On Thu, May 23, 2013 at 11:13 AM, Maarten Lankhorst
wrote:
>> 2. Do you really want to drop the *_slow variants?
>> Doing so might reduce debugging slightly. I like method #2 in
>> ww-mutex-design.txt, it makes it very clear why you
>> would handle the *_slow case differently anyway.
> As you poi
to review.
>>> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
>>> From: Maarten Lankhorst
>>>
>>> Changes since RFC patch v1:
>>> - Updated to use atomic_long instead of atomic, since the reservation_id
>>> was a l
On Thu, May 23, 2013 at 11:13 AM, Maarten Lankhorst
wrote:
>> 2. Do you really want to drop the *_slow variants?
>> Doing so might reduce debugging slightly. I like method #2 in
>> ww-mutex-design.txt, it makes it very clear why you
>> would handle the *_slow case differently anyway.
> As you poi
to review.
>>> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
>>> From: Maarten Lankhorst
>>>
>>> Changes since RFC patch v1:
>>> - Updated to use atomic_long instead of atomic, since the reservation_id
>>> was a l
Hey,
Op 22-05-13 18:18, Peter Zijlstra schreef:
> On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:
>
> Lacking the actual msg atm, I'm going to paste in here...
Thanks for taking the time to review.
>> Subject: [PATCH v3 2/3] mutex: add support for wound/
t;> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
>> From: Maarten Lankhorst
>>
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_res
On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:
Lacking the actual msg atm, I'm going to paste in here...
> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
> From: Maarten Lankhorst
>
> Changes since RFC patch v1:
> - Update
On Wed, May 22, 2013 at 01:47:42PM +0200, Maarten Lankhorst wrote:
> Op 22-05-13 13:37, Peter Zijlstra schreef:
> >> Are there any issues left? I included the patch you wrote for injecting
> >> -EDEADLK too
> >> in my tree. The overwhelming silence makes me think there are either none,
> >> or
>
Op 22-05-13 13:37, Peter Zijlstra schreef:
>> Are there any issues left? I included the patch you wrote for injecting
>> -EDEADLK too
>> in my tree. The overwhelming silence makes me think there are either none, or
>> nobody cared enough to review it. :(
> It didn't manage to reach my inbox it see
> Are there any issues left? I included the patch you wrote for injecting
> -EDEADLK too
> in my tree. The overwhelming silence makes me think there are either none, or
> nobody cared enough to review it. :(
It didn't manage to reach my inbox it seems,.. I can only find a debug
patch in this thre
Hey,
Op 30-04-13 21:14, Daniel Vetter schreef:
> On Sun, Apr 28, 2013 at 07:04:07PM +0200, Maarten Lankhorst wrote:
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_reserve_lock_slow and mutex_reserve_lock
Hey,
Op 22-05-13 18:18, Peter Zijlstra schreef:
> On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:
>
> Lacking the actual msg atm, I'm going to paste in here...
Thanks for taking the time to review.
>> Subject: [PATCH v3 2/3] mutex: add support for wound/
t;> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
>> From: Maarten Lankhorst
>>
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_res
On Wed, May 22, 2013 at 01:18:14PM +0200, Maarten Lankhorst wrote:
Lacking the actual msg atm, I'm going to paste in here...
> Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
> From: Maarten Lankhorst
>
> Changes since RFC patch v1:
&g
On Wed, May 22, 2013 at 01:47:42PM +0200, Maarten Lankhorst wrote:
> Op 22-05-13 13:37, Peter Zijlstra schreef:
> >> Are there any issues left? I included the patch you wrote for injecting
> >> -EDEADLK too
> >> in my tree. The overwhelming silence makes me think there are either none,
> >> or
>
Op 22-05-13 13:37, Peter Zijlstra schreef:
>> Are there any issues left? I included the patch you wrote for injecting
>> -EDEADLK too
>> in my tree. The overwhelming silence makes me think there are either none, or
>> nobody cared enough to review it. :(
> It didn't manage to reach my inbox it see
> Are there any issues left? I included the patch you wrote for injecting
> -EDEADLK too
> in my tree. The overwhelming silence makes me think there are either none, or
> nobody cared enough to review it. :(
It didn't manage to reach my inbox it seems,.. I can only find a debug
patch in this thre
Hey,
Op 30-04-13 21:14, Daniel Vetter schreef:
> On Sun, Apr 28, 2013 at 07:04:07PM +0200, Maarten Lankhorst wrote:
>> Changes since RFC patch v1:
>> - Updated to use atomic_long instead of atomic, since the reservation_id
>> was a long.
>> - added mutex_reserve_lock_slow and mutex_reserve_lock
On Sun, Apr 28, 2013 at 07:04:07PM +0200, Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_i
On Sun, Apr 28, 2013 at 07:04:07PM +0200, Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_i
Changes since RFC patch v1:
- Updated to use atomic_long instead of atomic, since the reservation_id was a
long.
- added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
- removed mutex_locked_set_reservation_id (or w/e it was called)
Changes since RFC patch v2:
- remove use of __mutex
Changes since RFC patch v1:
- Updated to use atomic_long instead of atomic, since the reservation_id was a
long.
- added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
- removed mutex_locked_set_reservation_id (or w/e it was called)
Changes since RFC patch v2:
- remove use of __mutex
48 matches
Mail list logo
