On Sun, 2005-04-10 at 12:31 +0200, Ingo Molnar wrote:
> looks much cleaner than earlier ones. Would it be possible to make the
> locks per journal? [...]
I've already looked into doing this, but it would be much more intrusive
to implement. The problem lies where these locks are called with
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > > yeah - i think Andrew said that a global lock at that particular place
> > > might not be that much of an issue.
> >
> > OK, I'll start stripping it out of my kernel today and make a clean
> > patch for you.
>
> Ingo, I haven't forgotten about
* Steven Rostedt [EMAIL PROTECTED] wrote:
yeah - i think Andrew said that a global lock at that particular place
might not be that much of an issue.
OK, I'll start stripping it out of my kernel today and make a clean
patch for you.
Ingo, I haven't forgotten about this, I just
On Sun, 2005-04-10 at 12:31 +0200, Ingo Molnar wrote:
looks much cleaner than earlier ones. Would it be possible to make the
locks per journal? [...]
I've already looked into doing this, but it would be much more intrusive
to implement. The problem lies where these locks are called with only
On Fri, 2005-04-01 at 07:27 -0500, Steven Rostedt wrote:
> On Fri, 2005-04-01 at 07:19 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >
> > > > could you send me your latest patch for the bit-spin issue? My main
> > > > issue was cleanliness, so that the patch doesnt
On Fri, 2005-04-01 at 07:27 -0500, Steven Rostedt wrote:
On Fri, 2005-04-01 at 07:19 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
could you send me your latest patch for the bit-spin issue? My main
issue was cleanliness, so that the patch doesnt get stuck in
On Fri, 2005-04-01 at 07:19 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > > could you send me your latest patch for the bit-spin issue? My main
> > > issue was cleanliness, so that the patch doesnt get stuck in the -RT
> > > tree forever.
> >
> > I think that's
On Fri, 2005-04-01 at 07:19 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
could you send me your latest patch for the bit-spin issue? My main
issue was cleanliness, so that the patch doesnt get stuck in the -RT
tree forever.
I think that's the main problem.
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > could you send me your latest patch for the bit-spin issue? My main
> > issue was cleanliness, so that the patch doesnt get stuck in the -RT
> > tree forever.
>
> I think that's the main problem. Without changing the design of the
> ext3
On Fri, 2005-04-01 at 06:43 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo,
> >
> > I was wondering if the issue the bit_spin_lock has gone into the side
> > burner? [...]
>
> could you send me your latest patch for the bit-spin issue? My main
> issue
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> I was wondering if the issue the bit_spin_lock has gone into the side
> burner? [...]
could you send me your latest patch for the bit-spin issue? My main
issue was cleanliness, so that the patch doesnt get stuck in the -RT
tree
Hi Ingo,
I was wondering if the issue the bit_spin_lock has gone into the side
burner? I understand that this is a major problem to change it, if you
want to get into the mainline kernel. But I still believe it to be a
problem. With kjournald spinning on a bit lock until it finishes it's
quota,
On Thursday 31 March 2005 13:17, Gene Heskett wrote:
>On Thursday 31 March 2005 12:49, Ingo Molnar wrote:
>>* Steven Rostedt <[EMAIL PROTECTED]> wrote:
>>> Oh, and did your really want to assign debug = .1?
>>>
>>> - .debug = .1, .file = __FILE__, .line = __LINE__
>>> + .debug = 1, .file =
On Thu, 2005-03-31 at 19:49 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Oh, and did your really want to assign debug = .1?
>
> > - .debug = .1, .file = __FILE__, .line = __LINE__
> > + .debug = 1, .file = __FILE__, .line = __LINE__
>
> doh - indeed. This
On Thursday 31 March 2005 12:49, Ingo Molnar wrote:
>* Steven Rostedt <[EMAIL PROTECTED]> wrote:
>> Oh, and did your really want to assign debug = .1?
>>
>> - .debug = .1, .file = __FILE__, .line = __LINE__
>> + .debug = 1, .file = __FILE__, .line = __LINE__
>
>doh - indeed. This means rwlocks
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Oh, and did your really want to assign debug = .1?
> - .debug = .1, .file = __FILE__, .line = __LINE__
> + .debug = 1, .file = __FILE__, .line = __LINE__
doh - indeed. This means rwlocks were nondebug all along? Ouch. I've
uploaded -42-08
On Thu, 2005-03-31 at 16:10 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > One more thing. Was this on SMP or UP. I haven't tested this on SMP
> > yet. When my laptop (HT) gets done with its work, I'll give it a try
> > there. Of course I need to disable NVidia
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> One more thing. Was this on SMP or UP. I haven't tested this on SMP
> yet. When my laptop (HT) gets done with its work, I'll give it a try
> there. Of course I need to disable NVidia on it first.
i've booted the latest tree on a 4-way testbox and
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > I was going to say the opposit. I know that there are many more rt_locks
> > locks around and the fields thus will take more memory when put there but
> > I believe it is more logical to have the fields there.
>
> It seems logical to be there, but
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > I'll play around some more with this.
>
> Oops! Found a little bug. Ingo, see if this fixes it.
yeah, that was it. I've uploaded -42-02 with the fix included.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, 2005-03-31 at 07:36 -0500, Steven Rostedt wrote:
> On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> > * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> Since this happened with the trylock, do you see anyway that a pending
> owner can cause problems? Maybe this has to do with
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
> knodemgrd_0/902: BUG in __down_complete at kernel/rt.c:1568
> [] dump_stack+0x23/0x25 (20)
> [] down_trylock+0x1fb/0x200 (48)
> [] nodemgr_host_thread+0xd0/0x17b (48)
> []
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> your patch looks good, i've added it to my tree and have uploaded the
> -26-00 patch. It boots fine on my testbox, except for some new messages:
>
> knodemgrd_0/902: BUG in __down_complete
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Well, here it finally is. There's still things I don't like about it.
> > But it seems to work, and that's the important part.
> >
> > I had to reluctantly add two items to the task_struct.
On Thu, 2005-03-31 at 13:03 +0100, Esben Nielsen wrote:
> On Thu, 31 Mar 2005, Ingo Molnar wrote:
>
> >
> > * Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >
> > > Well, here it finally is. There's still things I don't like about it.
> > > But it seems to work, and that's the important part.
> >
On Thu, 31 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Well, here it finally is. There's still things I don't like about it.
> > But it seems to work, and that's the important part.
> >
> > I had to reluctantly add two items to the task_struct. I was
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Well, here it finally is. There's still things I don't like about it.
> But it seems to work, and that's the important part.
>
> I had to reluctantly add two items to the task_struct. I was hoping
> to avoid that. But because of race conditions
* Steven Rostedt [EMAIL PROTECTED] wrote:
Well, here it finally is. There's still things I don't like about it.
But it seems to work, and that's the important part.
I had to reluctantly add two items to the task_struct. I was hoping
to avoid that. But because of race conditions it
On Thu, 31 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Well, here it finally is. There's still things I don't like about it.
But it seems to work, and that's the important part.
I had to reluctantly add two items to the task_struct. I was hoping
to
On Thu, 2005-03-31 at 13:03 +0100, Esben Nielsen wrote:
On Thu, 31 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Well, here it finally is. There's still things I don't like about it.
But it seems to work, and that's the important part.
I had to
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Well, here it finally is. There's still things I don't like about it.
But it seems to work, and that's the important part.
I had to reluctantly add two items to the task_struct. I was
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
your patch looks good, i've added it to my tree and have uploaded the
-26-00 patch. It boots fine on my testbox, except for some new messages:
knodemgrd_0/902: BUG in __down_complete at
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
knodemgrd_0/902: BUG in __down_complete at kernel/rt.c:1568
[c0103956] dump_stack+0x23/0x25 (20)
[c0130dcd] down_trylock+0x1fb/0x200 (48)
[c0364ee2] nodemgr_host_thread+0xd0/0x17b (48)
On Thu, 2005-03-31 at 07:36 -0500, Steven Rostedt wrote:
On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Since this happened with the trylock, do you see anyway that a pending
owner can cause problems? Maybe this has to do with is_locked.
* Steven Rostedt [EMAIL PROTECTED] wrote:
I'll play around some more with this.
Oops! Found a little bug. Ingo, see if this fixes it.
yeah, that was it. I've uploaded -42-02 with the fix included.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
* Steven Rostedt [EMAIL PROTECTED] wrote:
I was going to say the opposit. I know that there are many more rt_locks
locks around and the fields thus will take more memory when put there but
I believe it is more logical to have the fields there.
It seems logical to be there, but in
* Steven Rostedt [EMAIL PROTECTED] wrote:
One more thing. Was this on SMP or UP. I haven't tested this on SMP
yet. When my laptop (HT) gets done with its work, I'll give it a try
there. Of course I need to disable NVidia on it first.
i've booted the latest tree on a 4-way testbox and
On Thu, 2005-03-31 at 16:10 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
One more thing. Was this on SMP or UP. I haven't tested this on SMP
yet. When my laptop (HT) gets done with its work, I'll give it a try
there. Of course I need to disable NVidia on it
* Steven Rostedt [EMAIL PROTECTED] wrote:
Oh, and did your really want to assign debug = .1?
- .debug = .1, .file = __FILE__, .line = __LINE__
+ .debug = 1, .file = __FILE__, .line = __LINE__
doh - indeed. This means rwlocks were nondebug all along? Ouch. I've
uploaded -42-08 with
On Thursday 31 March 2005 12:49, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Oh, and did your really want to assign debug = .1?
- .debug = .1, .file = __FILE__, .line = __LINE__
+ .debug = 1, .file = __FILE__, .line = __LINE__
doh - indeed. This means rwlocks were nondebug
On Thu, 2005-03-31 at 19:49 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Oh, and did your really want to assign debug = .1?
- .debug = .1, .file = __FILE__, .line = __LINE__
+ .debug = 1, .file = __FILE__, .line = __LINE__
doh - indeed. This means rwlocks
On Thursday 31 March 2005 13:17, Gene Heskett wrote:
On Thursday 31 March 2005 12:49, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Oh, and did your really want to assign debug = .1?
- .debug = .1, .file = __FILE__, .line = __LINE__
+ .debug = 1, .file = __FILE__, .line =
Hi Ingo,
I was wondering if the issue the bit_spin_lock has gone into the side
burner? I understand that this is a major problem to change it, if you
want to get into the mainline kernel. But I still believe it to be a
problem. With kjournald spinning on a bit lock until it finishes it's
quota,
* Steven Rostedt [EMAIL PROTECTED] wrote:
Hi Ingo,
I was wondering if the issue the bit_spin_lock has gone into the side
burner? [...]
could you send me your latest patch for the bit-spin issue? My main
issue was cleanliness, so that the patch doesnt get stuck in the -RT
tree forever.
On Fri, 2005-04-01 at 06:43 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Hi Ingo,
I was wondering if the issue the bit_spin_lock has gone into the side
burner? [...]
could you send me your latest patch for the bit-spin issue? My main
issue was cleanliness,
* Steven Rostedt [EMAIL PROTECTED] wrote:
could you send me your latest patch for the bit-spin issue? My main
issue was cleanliness, so that the patch doesnt get stuck in the -RT
tree forever.
I think that's the main problem. Without changing the design of the
ext3 system, I don't
On Wed, 2005-03-30 at 16:39 -0500, Steven Rostedt wrote:
> On Wed, 2005-03-30 at 14:56 -0500, Steven Rostedt wrote:
>
> > Because of the stupid BKL, I'm going with a combination of your idea and
> > my idea for the solution of pending owners. I originally wanted the
> > stealer of the lock to
On Wed, 2005-03-30 at 14:56 -0500, Steven Rostedt wrote:
> Because of the stupid BKL, I'm going with a combination of your idea and
> my idea for the solution of pending owners. I originally wanted the
> stealer of the lock to put the task that was robbed back on the list.
> But because of the
On Wed, 2005-03-30 at 20:44 +0100, Esben Nielsen wrote:
> On Wed, 30 Mar 2005, Steven Rostedt wrote:
>
> > [...]
> >
> > Heck, I'll make it bloat city till I get it working, and then tone it
> > down a little :-) And maybe later we can have a better solution for the
> > BKL.
> >
> What about
On Wed, 30 Mar 2005, Steven Rostedt wrote:
> [...]
>
> Heck, I'll make it bloat city till I get it working, and then tone it
> down a little :-) And maybe later we can have a better solution for the
> BKL.
>
What about removing it alltogether?
Seriously, how much work would it be to simply
On Wed, 2005-03-30 at 08:50 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > OK, I'm declaring defeat here. I've been fighting race conditions all
> > day, and it's now 1 in the morning where I live. It looks like this
> > implementation has no other choice but to
On Wed, 2005-03-30 at 08:50 +0200, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
OK, I'm declaring defeat here. I've been fighting race conditions all
day, and it's now 1 in the morning where I live. It looks like this
implementation has no other choice but to have the
On Wed, 30 Mar 2005, Steven Rostedt wrote:
[...]
Heck, I'll make it bloat city till I get it working, and then tone it
down a little :-) And maybe later we can have a better solution for the
BKL.
What about removing it alltogether?
Seriously, how much work would it be to simply remove
On Wed, 2005-03-30 at 20:44 +0100, Esben Nielsen wrote:
On Wed, 30 Mar 2005, Steven Rostedt wrote:
[...]
Heck, I'll make it bloat city till I get it working, and then tone it
down a little :-) And maybe later we can have a better solution for the
BKL.
What about removing it
On Wed, 2005-03-30 at 14:56 -0500, Steven Rostedt wrote:
Because of the stupid BKL, I'm going with a combination of your idea and
my idea for the solution of pending owners. I originally wanted the
stealer of the lock to put the task that was robbed back on the list.
But because of the BKL,
On Wed, 2005-03-30 at 16:39 -0500, Steven Rostedt wrote:
On Wed, 2005-03-30 at 14:56 -0500, Steven Rostedt wrote:
Because of the stupid BKL, I'm going with a combination of your idea and
my idea for the solution of pending owners. I originally wanted the
stealer of the lock to put the
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> OK, I'm declaring defeat here. I've been fighting race conditions all
> day, and it's now 1 in the morning where I live. It looks like this
> implementation has no other choice but to have the waking up "pending
> owner" take the wait_list lock
On Sat, 2005-03-26 at 11:04 -0500, Steven Rostedt wrote:
>
> On Fri, 25 Mar 2005, Esben Nielsen wrote:
> >
> > I like the idea of having the scheduler take care of it - it is a very
> > optimal coded queue-system after all. That will work on UP but not on SMP.
> > Having the unlock operation to
On Sat, 2005-03-26 at 11:04 -0500, Steven Rostedt wrote:
On Fri, 25 Mar 2005, Esben Nielsen wrote:
I like the idea of having the scheduler take care of it - it is a very
optimal coded queue-system after all. That will work on UP but not on SMP.
Having the unlock operation to set the
* Steven Rostedt [EMAIL PROTECTED] wrote:
OK, I'm declaring defeat here. I've been fighting race conditions all
day, and it's now 1 in the morning where I live. It looks like this
implementation has no other choice but to have the waking up pending
owner take the wait_list lock once
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > i think this should be covered by the 'unschedule/unwakeup' feature,
> > mentioned in the latest mails.
>
> The first implementation would probably just be the setting of a
> "pending owner" bit. But the better one may be to unschedule. But,
>
On Fri, 25 Mar 2005, Ingo Molnar wrote:
> * Esben Nielsen <[EMAIL PROTECTED]> wrote:
>
> > I like the idea of having the scheduler take care of it - it is a very
> > optimal coded queue-system after all. That will work on UP but not on
> > SMP. Having the unlock operation to set the mutex in a
On Fri, 25 Mar 2005, Esben Nielsen wrote:
> >
>
> I checked the implementation of a mutex I send in last fall. The unlock
> operation does give ownership explicitly to the highest priority waiter,
> as Ingo's implementation does.
>
> Originally I planned for just having unlock to wake up the
On Fri, 25 Mar 2005, Esben Nielsen wrote:
I checked the implementation of a mutex I send in last fall. The unlock
operation does give ownership explicitly to the highest priority waiter,
as Ingo's implementation does.
Originally I planned for just having unlock to wake up the highest
On Fri, 25 Mar 2005, Ingo Molnar wrote:
* Esben Nielsen [EMAIL PROTECTED] wrote:
I like the idea of having the scheduler take care of it - it is a very
optimal coded queue-system after all. That will work on UP but not on
SMP. Having the unlock operation to set the mutex in a partially
* Steven Rostedt [EMAIL PROTECTED] wrote:
i think this should be covered by the 'unschedule/unwakeup' feature,
mentioned in the latest mails.
The first implementation would probably just be the setting of a
pending owner bit. But the better one may be to unschedule. But,
what would
* Esben Nielsen <[EMAIL PROTECTED]> wrote:
> I like the idea of having the scheduler take care of it - it is a very
> optimal coded queue-system after all. That will work on UP but not on
> SMP. Having the unlock operation to set the mutex in a "partially
> owned" state will work better. The
On Thu, 24 Mar 2005, Ingo Molnar wrote:
>
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > Here we have more unnecessary schedules. So the condition to grab a
> > lock should be:
> >
> > 1. not owned.
> > 2. partially owned, and the owner is not RT.
> > 3. partially owned but the owner is
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On an SMP machine, there may even be a chance of a lower priority
> process that gets it. That would be possible if the low priority
> process on the other CPU tries to grab the lock just after it was
> released but before the just woken up high
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > but i think i like the 'partial owner' (or rather 'owner pending')
> > technique a bit better, because it controls concurrency explicitly, and
> > it would thus e.g. allow another trick: when a new owner 'steals' a lock
> > from another in-flight
On Thu, 24 Mar 2005, Ingo Molnar wrote:
>
> there's another approach that could solve this problem: let the
> scheduler sort it all out. Esben Nielsen had this suggestion a couple of
> months ago - i didnt follow it because i thought that technique would
> create too many runnable tasks, but
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Here we have more unnecessary schedules. So the condition to grab a
> lock should be:
>
> 1. not owned.
> 2. partially owned, and the owner is not RT.
> 3. partially owned but the owner is RT and so is the grabber, and the
> grabber's priority
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> I also see this with non rt tasks causing a burst of schedules.
>
> 1. Process A runs and grabs lock L. then finishes its time slice.
> 2. Process B runs and tries to grab Lock L.
> 3. Process A runs and releases lock L.
> 4. __up_mutex gives
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> This way when process C tries to get the lock again, it sees that it's
> owned, but B hasn't executed yet. So it would be safe for C to take
> the lock back from B, that is if C is greater priority than B,
> otherwise it would act the same.
On Thu, 24 Mar 2005, Steven Rostedt wrote:
>
> I've noticed the following situation which is caused by __up_mutex
> assigning an owner right away.
>
I also see this with non rt tasks causing a burst of schedules.
1. Process A runs and grabs lock L. then finishes its time slice.
2. Process B runs
Ingo,
I've noticed the following situation which is caused by __up_mutex
assigning an owner right away.
Given 3 processes, with priorities 1, 2, 3, where 3 is highest and 1 is
lowest, and call them process A, B, C respectively.
1. Process A runs and grabs Lock L.
2. Process B preempts A,
Ingo,
I've noticed the following situation which is caused by __up_mutex
assigning an owner right away.
Given 3 processes, with priorities 1, 2, 3, where 3 is highest and 1 is
lowest, and call them process A, B, C respectively.
1. Process A runs and grabs Lock L.
2. Process B preempts A,
On Thu, 24 Mar 2005, Steven Rostedt wrote:
I've noticed the following situation which is caused by __up_mutex
assigning an owner right away.
I also see this with non rt tasks causing a burst of schedules.
1. Process A runs and grabs lock L. then finishes its time slice.
2. Process B runs and
* Steven Rostedt [EMAIL PROTECTED] wrote:
This way when process C tries to get the lock again, it sees that it's
owned, but B hasn't executed yet. So it would be safe for C to take
the lock back from B, that is if C is greater priority than B,
otherwise it would act the same.
agreed. In
* Steven Rostedt [EMAIL PROTECTED] wrote:
I also see this with non rt tasks causing a burst of schedules.
1. Process A runs and grabs lock L. then finishes its time slice.
2. Process B runs and tries to grab Lock L.
3. Process A runs and releases lock L.
4. __up_mutex gives process B lock
* Steven Rostedt [EMAIL PROTECTED] wrote:
Here we have more unnecessary schedules. So the condition to grab a
lock should be:
1. not owned.
2. partially owned, and the owner is not RT.
3. partially owned but the owner is RT and so is the grabber, and the
grabber's priority is = the
On Thu, 24 Mar 2005, Ingo Molnar wrote:
there's another approach that could solve this problem: let the
scheduler sort it all out. Esben Nielsen had this suggestion a couple of
months ago - i didnt follow it because i thought that technique would
create too many runnable tasks, but maybe
* Steven Rostedt [EMAIL PROTECTED] wrote:
but i think i like the 'partial owner' (or rather 'owner pending')
technique a bit better, because it controls concurrency explicitly, and
it would thus e.g. allow another trick: when a new owner 'steals' a lock
from another in-flight task, then
* Steven Rostedt [EMAIL PROTECTED] wrote:
On an SMP machine, there may even be a chance of a lower priority
process that gets it. That would be possible if the low priority
process on the other CPU tries to grab the lock just after it was
released but before the just woken up high priorty
On Thu, 24 Mar 2005, Ingo Molnar wrote:
* Steven Rostedt [EMAIL PROTECTED] wrote:
Here we have more unnecessary schedules. So the condition to grab a
lock should be:
1. not owned.
2. partially owned, and the owner is not RT.
3. partially owned but the owner is RT and so is the
* Esben Nielsen [EMAIL PROTECTED] wrote:
I like the idea of having the scheduler take care of it - it is a very
optimal coded queue-system after all. That will work on UP but not on
SMP. Having the unlock operation to set the mutex in a partially
owned state will work better. The only
On Thu, Mar 24, 2005 at 06:34:56AM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > Now, it is true that CPU#2 might record a quiescent state during this
> > time, but this will have no effect because -all- CPUs must pass
> > through a quiescent state before
On Wed, Mar 23, 2005 at 10:46:45PM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > i think the 'migrate read-count' method is not adequate either,
> > because all callbacks queued within an RCU read section must be called
> > after the lock has been dropped - while
On Wed, Mar 23, 2005 at 08:49:54PM +1100, Herbert Xu wrote:
> On Wed, Mar 23, 2005 at 08:38:11PM +1100, Herbert Xu wrote:
> >
> > > ok. It's enough to put a barrier into the else branch here, because the
> > > atomic op in the main brain is a barrier by itself.
> >
> > Since the else branch is
On Wed, Mar 23, 2005 at 10:03:41AM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > > i think the 'migrate read-count' method is not adequate either, because
> > > all callbacks queued within an RCU read section must be called after the
> > > lock has been dropped
On Wed, Mar 23, 2005 at 08:16:04AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > That callback will be queued on CPU#2 - while the task still keeps
> > current->rcu_data of CPU#1. It also means that CPU#2's read counter
> > did _not_ get increased - and a too short
On Wed, Mar 23, 2005 at 07:37:27AM +0100, Ingo Molnar wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > the 'migrate read count' solution seems more promising, as it would
> > keep other parts of the RCU code unchanged. [ But it seems to break
> > the nice 'flip pointers' method you
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> Now, it is true that CPU#2 might record a quiescent state during this
> time, but this will have no effect because -all- CPUs must pass
> through a quiescent state before any callbacks will be invoked. Since
> CPU#1 is refusing to record a
On Wed, Mar 23, 2005 at 07:33:17AM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> > +#ifdef CONFIG_PREEMPT_RCU
> > +
> > +void rcu_read_lock(void)
> > +{
> > + if (current->rcu_read_lock_nesting++ == 0) {
> > + current->rcu_data = _cpu_var(rcu_data);
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i think the 'migrate read-count' method is not adequate either,
> because all callbacks queued within an RCU read section must be called
> after the lock has been dropped - while with the migration method
> CPU#1 would be free to process callbacks
On Wed, Mar 23, 2005 at 08:38:11PM +1100, Herbert Xu wrote:
>
> > ok. It's enough to put a barrier into the else branch here, because the
> > atomic op in the main brain is a barrier by itself.
>
> Since the else branch is only taken when rcu_read_lock_nesting > 0, do
> we need the barrier at
On Wed, Mar 23, 2005 at 08:40:58PM +1100, Herbert Xu wrote:
> Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> >
> > +void rcu_read_unlock(void)
> > +{
> > + int cpu;
> > +
> > + if (--current->rcu_read_lock_nesting == 0) {
> > + atomic_dec(>rcu_data->active_readers);
> > +
Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
> +void rcu_read_unlock(void)
> +{
> + int cpu;
> +
> + if (--current->rcu_read_lock_nesting == 0) {
> + atomic_dec(>rcu_data->active_readers);
> + /*
> +* Check whether we have reached quiescent
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Paul E. McKenney <[EMAIL PROTECTED]> wrote:
>
>> +#ifdef CONFIG_PREEMPT_RCU
>> +
>> +void rcu_read_lock(void)
>> +{
>> + if (current->rcu_read_lock_nesting++ == 0) {
>> + current->rcu_data = _cpu_var(rcu_data);
>> +
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > i think the 'migrate read-count' method is not adequate either, because
> > all callbacks queued within an RCU read section must be called after the
> > lock has been dropped - while with the migration method CPU#1 would be
> > free to process
1 - 100 of 134 matches
Mail list logo