On Wed, Apr 17, 2013 at 09:08:17PM +0200, Daniel Vetter wrote:
> On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt
> wrote:
> > On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
> >> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> >> > The thing is now that you're not
On Wed, Apr 17, 2013 at 09:08:17PM +0200, Daniel Vetter wrote:
On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
The thing is now that you're
On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt wrote:
> On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
>> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> > The thing is now that you're not expected to hold these locks for a
>> > long
>> > time - if you need to
On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
The thing is now that you're not expected to hold these locks for a
long
time - if you need to
On Mon, Apr 08, 2013 at 01:50:26PM +0200, Daniel Vetter wrote:
> On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
> > On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> > > Presuming I'm still following we should be able to fix this with the
> > > new sleep state
On Tue, Apr 09, 2013 at 06:28:08PM -0400, Steven Rostedt wrote:
> On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
> > On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > > The thing is now that you're not expected to hold these locks for a
> > > long
> > > time - if you
On Wed, Apr 10, 2013 at 12:27 AM, Steven Rostedt wrote:
> On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
>> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> > Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
>> > wait
>> > times of older task.
>>
>>
On Tue, 2013-04-09 at 18:42 -0400, Steven Rostedt wrote:
> What about setting an age as soon as it starts the process
> of grabbing one of these locks? And it keeps the age until it
> successfully grabs and releases all the locks again. It wont reset if
> it
> had to drop the locks and start over.
On Tue, 2013-04-09 at 18:42 -0400, Steven Rostedt wrote:
What about setting an age as soon as it starts the process
of grabbing one of these locks? And it keeps the age until it
successfully grabs and releases all the locks again. It wont reset if
it
had to drop the locks and start over.
On Wed, Apr 10, 2013 at 12:27 AM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
wait
times of older task.
On Mon, Apr 08, 2013 at 01:50:26PM +0200, Daniel Vetter wrote:
On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
Presuming I'm still following we should be able to fix this with the
new sleep state TASK_DEADLOCK and a
On Thu, Apr 04, 2013 at 06:56:58PM +0200, Daniel Vetter wrote:
>
> I think for starters we need to have a slightly more interesting example:
>
> 3 threads O, M, Y: O has the oldest ww_age/ticket, Y the youngest, M
> is in between.
> 2 ww_mutexes: A, B
>
> Y has already acquired ww_mutex A, M
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > The thing is now that you're not expected to hold these locks for a
> > long
> > time - if you need to synchronously stall while holding a lock
> > performance
> > will go
On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
> > wait
> > times of older task.
>
> No, imagine the following:
>
> struct ww_mutex A, B;
> struct
On Tue, Apr 02, 2013 at 06:59:14PM +0200, Peter Zijlstra wrote:
>
> So how about we call the thing something like:
>
> struct ww_mutex; /* wound/wait */
Reading this I can't help but think of Elmer Fudd saying "Round Robin"
as "Wound Wobin"
-- Steve
>
> int mutex_wound_lock(struct
On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
wait
times of older task.
No, imagine the following:
struct ww_mutex A, B;
struct mutex C;
On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
The thing is now that you're not expected to hold these locks for a
long
time - if you need to synchronously stall while holding a lock
performance
will go down the
On Tue, Apr 02, 2013 at 06:59:14PM +0200, Peter Zijlstra wrote:
So how about we call the thing something like:
struct ww_mutex; /* wound/wait */
Reading this I can't help but think of Elmer Fudd saying Round Robin
as Wound Wobin
-- Steve
int mutex_wound_lock(struct ww_mutex *); /*
On Thu, Apr 04, 2013 at 06:56:58PM +0200, Daniel Vetter wrote:
I think for starters we need to have a slightly more interesting example:
3 threads O, M, Y: O has the oldest ww_age/ticket, Y the youngest, M
is in between.
2 ww_mutexes: A, B
Y has already acquired ww_mutex A, M has
On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> > Presuming I'm still following we should be able to fix this with the
> > new sleep state TASK_DEADLOCK and a flag somewhere in the thread info
> > (let's call it PF_GTFO
On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter wrote:
> >> In this case when O blocks Y isn't actually blocked, so our
> >> TASK_DEADLOCK wakeup doesn't actually achieve anything.
> >>
> >> This means we also have to track (task) state so
On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter dan...@ffwll.ch wrote:
In this case when O blocks Y isn't actually blocked, so our
TASK_DEADLOCK wakeup doesn't actually achieve anything.
This means we also have to track (task) state so
On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
Presuming I'm still following we should be able to fix this with the
new sleep state TASK_DEADLOCK and a flag somewhere in the thread info
(let's call it PF_GTFO for
On Thu, Apr 4, 2013 at 6:49 PM, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> We've discussed this approach of using (rt-prio, age) instead of just
>> age
>> to determine the the "oldness" of a task for deadlock-breaking with
>> -EAGAIN. The problem is that
On Thu, Apr 4, 2013 at 6:38 PM, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
>> wait
>> times of older task.
>
> No, imagine the following:
>
> struct ww_mutex A, B;
> struct mutex C;
>
>
On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter wrote:
>> In this case when O blocks Y isn't actually blocked, so our
>> TASK_DEADLOCK wakeup doesn't actually achieve anything.
>>
>> This means we also have to track (task) state so that once Y tries to
>> acquire A (creating the actual deadlock)
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> Well, it was a good read and I'm rather happy that we agree on the
> ww_ctx
> thing (whatever it's called in the end), even though we have slightly
> different reasons for it.
Yeah, I tried various weirdness to get out from under it, but
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> We've discussed this approach of using (rt-prio, age) instead of just
> age
> to determine the the "oldness" of a task for deadlock-breaking with
> -EAGAIN. The problem is that through PI boosting or normal rt-prio
> changes
> while tasks
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> I'm a bit confused about the different classes you're talking about.
> Since
> the ticket queue is currently a global counter there's only one class
> of
> ww_mutexes.
Right, so that's not something that's going to fly.. we need to
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> Another big reason for having a start/end marker like you've describe
> is
> lockdep support.
Yeah, I saw how you did that.. but there's other ways of making it work
too, you could for instance create a new validation state for this type
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> The thing is now that you're not expected to hold these locks for a
> long
> time - if you need to synchronously stall while holding a lock
> performance
> will go down the gutters anyway. And since most current
> gpus/co-processors
> still
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> The trick with the current code is that the oldest task
> will never see an -EAGAIN ever and hence is guaranteed to make forward
> progress. If the task is really unlucky though it might be forced to
> wait
> for a younger task for every
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
> wait
> times of older task.
No, imagine the following:
struct ww_mutex A, B;
struct mutex C;
task-O task-Y task-X
A
B
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> We do add some form of owner tracking by storing the reservation
> ticket
> of the current holder into every ww_mutex. So when task-Y in your
> above
> example tries to acquire lock A it notices that it's behind in the
> global
> queue and
On Thu, Apr 04, 2013 at 02:01:48PM +0200, Peter Zijlstra wrote:
>
> I'm sorry, this email ended up quite a bit longer than I had hoped for;
> please bear with me.
>
> On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote:
> > struct ww_mutex; /* wound/wait */
> >
> > int
I'm sorry, this email ended up quite a bit longer than I had hoped for;
please bear with me.
On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote:
> struct ww_mutex; /* wound/wait */
>
> int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */
> int mutex_wait_lock(struct
I'm sorry, this email ended up quite a bit longer than I had hoped for;
please bear with me.
On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote:
struct ww_mutex; /* wound/wait */
int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */
int mutex_wait_lock(struct ww_mutex
On Thu, Apr 04, 2013 at 02:01:48PM +0200, Peter Zijlstra wrote:
I'm sorry, this email ended up quite a bit longer than I had hoped for;
please bear with me.
On Tue, 2013-04-02 at 18:59 +0200, Peter Zijlstra wrote:
struct ww_mutex; /* wound/wait */
int mutex_wound_lock(struct
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
wait
times of older task.
No, imagine the following:
struct ww_mutex A, B;
struct mutex C;
task-O task-Y task-X
A
B
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
The trick with the current code is that the oldest task
will never see an -EAGAIN ever and hence is guaranteed to make forward
progress. If the task is really unlucky though it might be forced to
wait
for a younger task for every
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
The thing is now that you're not expected to hold these locks for a
long
time - if you need to synchronously stall while holding a lock
performance
will go down the gutters anyway. And since most current
gpus/co-processors
still can't
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
Another big reason for having a start/end marker like you've describe
is
lockdep support.
Yeah, I saw how you did that.. but there's other ways of making it work
too, you could for instance create a new validation state for this type
of
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
I'm a bit confused about the different classes you're talking about.
Since
the ticket queue is currently a global counter there's only one class
of
ww_mutexes.
Right, so that's not something that's going to fly.. we need to support
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
We've discussed this approach of using (rt-prio, age) instead of just
age
to determine the the oldness of a task for deadlock-breaking with
-EAGAIN. The problem is that through PI boosting or normal rt-prio
changes
while tasks are
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
Well, it was a good read and I'm rather happy that we agree on the
ww_ctx
thing (whatever it's called in the end), even though we have slightly
different reasons for it.
Yeah, I tried various weirdness to get out from under it, but the
On Thu, Apr 4, 2013 at 3:31 PM, Daniel Vetter dan...@ffwll.ch wrote:
In this case when O blocks Y isn't actually blocked, so our
TASK_DEADLOCK wakeup doesn't actually achieve anything.
This means we also have to track (task) state so that once Y tries to
acquire A (creating the actual
On Thu, Apr 4, 2013 at 6:38 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
wait
times of older task.
No, imagine the following:
struct ww_mutex A, B;
struct mutex C;
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
We do add some form of owner tracking by storing the reservation
ticket
of the current holder into every ww_mutex. So when task-Y in your
above
example tries to acquire lock A it notices that it's behind in the
global
queue and
On Thu, Apr 4, 2013 at 6:49 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
We've discussed this approach of using (rt-prio, age) instead of just
age
to determine the the oldness of a task for deadlock-breaking with
-EAGAIN. The problem
On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra
wrote:
>> > Also, is there anything in CS literature that comes close to this? I'd
>> > think the DBMS people would have something similar with their
>> > transactional systems. What do they call it?
>
>> I didn't study cs, but judging from your
On Tue, Apr 2, 2013 at 6:59 PM, Peter Zijlstra
wrote:
>> > Head hurts, needs more time to ponder. It would be good if someone else
>> > (this would probably be you maarten) would also consider this explore
>> > this 'interesting' problem space :-)
>
>> My head too, evil priority stuff!
>>
>>
On Tue, 2013-04-02 at 16:57 +0200, Maarten Lankhorst wrote:
> Hey,
>
> Thanks for reviewing.
Only partway through so far :-)
> Op 02-04-13 13:00, Peter Zijlstra schreef:
> > On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> >> +Reservation type mutexes
> >> +struct ticket_mutex {
>
On Tue, Apr 2, 2013 at 1:00 PM, Peter Zijlstra
wrote:
> Also, is there anything in CS literature that comes close to this? I'd
> think the DBMS people would have something similar with their
> transactional systems. What do they call it?
I've looked around a bit and in dbms row-locking land
Hey,
Thanks for reviewing.
Op 02-04-13 13:00, Peter Zijlstra schreef:
> On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
>> +Reservation type mutexes
>> +struct ticket_mutex {
>> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
> That's two different names and
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +The algorithm that TTM came up with for dealing with this problem is
> +quite simple. For each group of buffers (execbuf) that need to be
> +locked, the caller would be assigned a unique reservation_id, from a
> +global counter. In
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +Reservation type mutexes
> +struct ticket_mutex {
> +extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
That's two different names and two different forms of one (for a total
of 3 variants) for the same scheme.
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +struct ticket_mutex {
> + struct mutex base;
> + atomic_long_t reservation_id;
> +};
I'm not sure this is a good name, esp. due to the potential confusion
vs the ticket spinlocks we have.
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
> +mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
> + Similar to mutex_reserve_lock, except it won't backoff with
> -EAGAIN.
> + This is useful when mutex_reserve_lock failed with -EAGAIN, and you
> + unreserved all
Hey,
Thanks for reviewing.
Op 02-04-13 13:00, Peter Zijlstra schreef:
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
+Reservation type mutexes
+struct ticket_mutex {
+extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
That's two different names and two
On Tue, Apr 2, 2013 at 1:00 PM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
Also, is there anything in CS literature that comes close to this? I'd
think the DBMS people would have something similar with their
transactional systems. What do they call it?
I've looked around a bit and in dbms
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
+struct ticket_mutex {
+ struct mutex base;
+ atomic_long_t reservation_id;
+};
I'm not sure this is a good name, esp. due to the potential confusion
vs the ticket spinlocks we have.
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
+Reservation type mutexes
+struct ticket_mutex {
+extern int __must_check _mutex_reserve_lock(struct ticket_mutex *lock,
That's two different names and two different forms of one (for a total
of 3 variants) for the same scheme.
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
+The algorithm that TTM came up with for dealing with this problem is
+quite simple. For each group of buffers (execbuf) that need to be
+locked, the caller would be assigned a unique reservation_id, from a
+global counter. In case
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
+mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
+ Similar to mutex_reserve_lock, except it won't backoff with
-EAGAIN.
+ This is useful when mutex_reserve_lock failed with -EAGAIN, and you
+ unreserved all
On Tue, 2013-04-02 at 16:57 +0200, Maarten Lankhorst wrote:
Hey,
Thanks for reviewing.
Only partway through so far :-)
Op 02-04-13 13:00, Peter Zijlstra schreef:
On Thu, 2013-02-28 at 11:25 +0100, Maarten Lankhorst wrote:
+Reservation type mutexes
+struct ticket_mutex {
+extern int
New version. All of the documentation has been moved from the commit log to
Documentation/reservation-mutex-design.txt
Missing at the moment, maybe TODO?
Add a lockdep check in the *_slow calls that verifies that the lock
being nested into has no nested lock any more? This would be a check
to
66 matches
Mail list logo
