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
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
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 =
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
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 when
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(ww_class-stamp);
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 missing rationale.
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 on
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 as a normal
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 in the
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 {
+ ctx-stamp =
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 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 mutex
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 the
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 had to
On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra pet...@infradead.org 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 =
On Mon, May 27, 2013 at 4:47 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, May 27, 2013 at 10:21 AM, Peter Zijlstra pet...@infradead.org 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,
+
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
view.
>>> 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.
: add support for wound/wait style locks, v3
From: Maarten Lankhorst maarten.lankhorst@x
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
On Thu, May 23, 2013 at 11:13 AM, Maarten Lankhorst
maarten.lankho...@canonical.com 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
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/wait
ject: [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_reserve_lock_
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:
> -
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
> 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
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
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
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 thread.
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 seems,.. I
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
nobody cared
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 maarten.lankhorst@x
Changes since RFC patch v1
;-)
Subject: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
From: Maarten Lankhorst maarten.lankhorst@x
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
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/wait style locks, v3
From
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
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_id
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
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
48 matches
Mail list logo
