On Mon, 2005-04-18 at 00:37 -0700, Sven-Thorsten Dietrich wrote:
>
> Bill, we are really trying to do this right, open, on the table.
>
> This is an open invitation to anyone interested to get on the line
> with us on Wednesday. Get the info for the FREE call here:
>
>
On Sun, 2005-04-17 at 22:30 -0700, Bill Huey wrote:
> On Fri, Apr 15, 2005 at 04:37:05PM -0700, Inaky Perez-Gonzalez wrote:
> > By following your method, the pi engine becomes unnecesarily complex;
> > you have actually two engines following two different propagation
> > chains (one kernel, one
On Sun, 2005-04-17 at 22:30 -0700, Bill Huey wrote:
On Fri, Apr 15, 2005 at 04:37:05PM -0700, Inaky Perez-Gonzalez wrote:
By following your method, the pi engine becomes unnecesarily complex;
you have actually two engines following two different propagation
chains (one kernel, one user). If
On Mon, 2005-04-18 at 00:37 -0700, Sven-Thorsten Dietrich wrote:
Bill, we are really trying to do this right, open, on the table.
This is an open invitation to anyone interested to get on the line
with us on Wednesday. Get the info for the FREE call here:
On Fri, Apr 15, 2005 at 04:37:05PM -0700, Inaky Perez-Gonzalez wrote:
> By following your method, the pi engine becomes unnecesarily complex;
> you have actually two engines following two different propagation
> chains (one kernel, one user). If your mutexes/locks/whatever are the
> same with a
On Fri, Apr 15, 2005 at 04:37:05PM -0700, Inaky Perez-Gonzalez wrote:
By following your method, the pi engine becomes unnecesarily complex;
you have actually two engines following two different propagation
chains (one kernel, one user). If your mutexes/locks/whatever are the
same with a
Steven Rostedt wrote:
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
> Sven Dietrich wrote:
[...]
> > This one probably should be a raw_spinlock.
> > This lock is only held to protect access to the queues.
> > Since the queues are already priority ordered, there is
> > little benefit to ordering -the order of
Sven Dietrich wrote:
/** A fuqueue, a prioritized wait queue usable from
kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
Would the above spinlock_t be a raw_spinlock_t? This goes
back to my first question.
Sven Dietrich wrote:
/** A fuqueue, a prioritized wait queue usable from
kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
Would the above spinlock_t be a raw_spinlock_t? This goes
back to my first question.
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order of insertion-
Steven Rostedt wrote:
On Sat, 2005-04-16 at 09:05 -0400, john cooper wrote:
Sven Dietrich wrote:
[...]
This one probably should be a raw_spinlock.
This lock is only held to protect access to the queues.
Since the queues are already priority ordered, there is
little benefit to ordering -the order
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
>> > Steven Rostedt <[EMAIL PROTECTED]> writes:
>>
>> I see--would the following fit your view?
>>
> I think it's time that I take a look at the fusyn code. I don't have
> all
On Fri, 15 Apr 2005, Sven Dietrich wrote:
> > > >
> > > /** A fuqueue, a prioritized wait queue usable from
> > kernel space. */
> > > struct fuqueue {
> > > spinlock_t lock;
> > > struct plist wlist;
> > > struct fuqueue_ops *ops;
> > > };
> > >
> >
> >
> > >
> > /** A fuqueue, a prioritized wait queue usable from
> kernel space. */
> > struct fuqueue {
> > spinlock_t lock;
> > struct plist wlist;
> > struct fuqueue_ops *ops;
> > };
> >
>
> Would the above spinlock_t be a raw_spinlock_t?
On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
> > Steven Rostedt <[EMAIL PROTECTED]> writes:
>
> > On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
>
> >> Back to my example before: in fusyn, a user space lock is a kernel
> >> space lock with a wrapper, that
> Steven Rostedt <[EMAIL PROTECTED]> writes:
> On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
>> Back to my example before: in fusyn, a user space lock is a kernel
>> space lock with a wrapper, that provides all that is necessary for
>> doing the fast path and handling
On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
> > Steven Rostedt <[EMAIL PROTECTED]> writes:
> >> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
>
> > I have to agree with Inaky too. Fundamentally, PI is the same for
> > the system regardless of if the locks
> Steven Rostedt <[EMAIL PROTECTED]> writes:
>> On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> I have to agree with Inaky too. Fundamentally, PI is the same for
> the system regardless of if the locks are user or kernel. I still
> don't see the difference here. But for
On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
> > Bill Huey (hui) <[EMAIL PROTECTED]> writes:
>
> > Ok, I've been thinking about these issues and I believe there are a
> > number of misunderstandings here. The user and kernel space mutexes
> > need to be completely different
> Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> Ok, I've been thinking about these issues and I believe there are a
> number of misunderstandings here. The user and kernel space mutexes
> need to be completely different implementations. I'll have more on
> this later.
> First of all,
On Wed, Apr 13, 2005 at 11:46:40AM -0400, Steven Rostedt wrote:
> On Tue, 2005-04-12 at 17:27 -0700, Daniel Walker wrote:
> > There is a great big snag in my assumptions. It's possible for a process
> > to hold a fusyn lock, then block on an RT lock. In that situation you
> > could have a high
On Wed, Apr 13, 2005 at 11:46:40AM -0400, Steven Rostedt wrote:
On Tue, 2005-04-12 at 17:27 -0700, Daniel Walker wrote:
There is a great big snag in my assumptions. It's possible for a process
to hold a fusyn lock, then block on an RT lock. In that situation you
could have a high priority
Bill Huey (hui) [EMAIL PROTECTED] writes:
Ok, I've been thinking about these issues and I believe there are a
number of misunderstandings here. The user and kernel space mutexes
need to be completely different implementations. I'll have more on
this later.
First of all, priority
On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
Bill Huey (hui) [EMAIL PROTECTED] writes:
Ok, I've been thinking about these issues and I believe there are a
number of misunderstandings here. The user and kernel space mutexes
need to be completely different
Steven Rostedt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
I have to agree with Inaky too. Fundamentally, PI is the same for
the system regardless of if the locks are user or kernel. I still
don't see the difference here. But for other reasons,
On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
Steven Rostedt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 16:37 -0700, Inaky Perez-Gonzalez wrote:
I have to agree with Inaky too. Fundamentally, PI is the same for
the system regardless of if the locks are user or
Steven Rostedt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
Back to my example before: in fusyn, a user space lock is a kernel
space lock with a wrapper, that provides all that is necessary for
doing the fast path and handling user-space specific
On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
Steven Rostedt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 18:20 -0700, Inaky Perez-Gonzalez wrote:
Back to my example before: in fusyn, a user space lock is a kernel
space lock with a wrapper, that provides all that is
/** A fuqueue, a prioritized wait queue usable from
kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
Would the above spinlock_t be a raw_spinlock_t? This goes
back to
On Fri, 15 Apr 2005, Sven Dietrich wrote:
/** A fuqueue, a prioritized wait queue usable from
kernel space. */
struct fuqueue {
spinlock_t lock;
struct plist wlist;
struct fuqueue_ops *ops;
};
Would the above spinlock_t be a
Steven Rostedt [EMAIL PROTECTED] writes:
On Fri, 2005-04-15 at 18:53 -0700, Inaky Perez-Gonzalez wrote:
Steven Rostedt [EMAIL PROTECTED] writes:
I see--would the following fit your view?
I think it's time that I take a look at the fusyn code. I don't have
all the emails on this
On Wed, 2005-04-13 at 10:33 -0700, Daniel Walker wrote:
> On Wed, 2005-04-13 at 08:46, Steven Rostedt wrote:
> > How hard would it be to use the RT mutex PI for the priority inheritance
> > for fusyn? I only work with the RT mutex now and haven't looked at the
> > fusyn. Maybe Ingo can make a
On Wed, 2005-04-13 at 08:46, Steven Rostedt wrote:
> How hard would it be to use the RT mutex PI for the priority inheritance
> for fusyn? I only work with the RT mutex now and haven't looked at the
> fusyn. Maybe Ingo can make a separate PI system with its own API that
> both the fusyn and RT
On Tue, 2005-04-12 at 17:27 -0700, Daniel Walker wrote:
> There is a great big snag in my assumptions. It's possible for a process
> to hold a fusyn lock, then block on an RT lock. In that situation you
> could have a high priority user space process be scheduled then block on
> the same fusyn
On Tue, 2005-04-12 at 17:27 -0700, Daniel Walker wrote:
There is a great big snag in my assumptions. It's possible for a process
to hold a fusyn lock, then block on an RT lock. In that situation you
could have a high priority user space process be scheduled then block on
the same fusyn lock
On Wed, 2005-04-13 at 08:46, Steven Rostedt wrote:
How hard would it be to use the RT mutex PI for the priority inheritance
for fusyn? I only work with the RT mutex now and haven't looked at the
fusyn. Maybe Ingo can make a separate PI system with its own API that
both the fusyn and RT mutex
On Wed, 2005-04-13 at 10:33 -0700, Daniel Walker wrote:
On Wed, 2005-04-13 at 08:46, Steven Rostedt wrote:
How hard would it be to use the RT mutex PI for the priority inheritance
for fusyn? I only work with the RT mutex now and haven't looked at the
fusyn. Maybe Ingo can make a separate
There is a great big snag in my assumptions. It's possible for a process
to hold a fusyn lock, then block on an RT lock. In that situation you
could have a high priority user space process be scheduled then block on
the same fusyn lock but the PI wouldn't be fully transitive , plus there
will be
On 12 Apr 2005, Daniel Walker wrote:
>
> I just wanted to discuss the problem a little more. From all the
> conversations that I've had it seem that everyone is worried about
> having PI in Fusyn, and PI in the RT mutex.
>
> It seems like these two locks are going to interact on a very limited
>From: Esben Nielsen [mailto:[EMAIL PROTECTED]
>
>I think we (at least) got a bit confused here. What (I think) the
thread
>started out with was a clear layering of the mutexes. I.e. the code
obeys
>the grammar
>
> VALID_LOCK_CODE = LOCK_FUSYN VALID_LOCK_CODE UNLOCK_FUSYN
> |
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>On Tue, 2005-04-12 at 15:26, Perez-Gonzalez, Inaky wrote:
>
>> You should not need any of this if your user space mutexes are a
>> wrapper over the kernel space ones. The kernel handles everything
>> the same and there is no need to take care of any
On Tue, Apr 12, 2005 at 11:15:02AM -0700, Daniel Walker wrote:
> It seems like these two locks are going to interact on a very limited
> basis. Fusyn will be the user space mutex, and the RT mutex is only in
> the kernel. You can't lock an RT mutex and hold it, then lock a Fusyn
> mutex (anyone
I think we (at least) got a bit confused here. What (I think) the thread
started out with was a clear layering of the mutexes. I.e. the code obeys
the grammar
VALID_LOCK_CODE = LOCK_FUSYN VALID_LOCK_CODE UNLOCK_FUSYN
| VALID_LOCK_CODE VALID_LOCK_CODE
|
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
>
>> So no, you will not need the same API, at all :-) Fusyn manipulates
>> task->static_prio and only task->prio when no RT lock is taken. When
the
>> first RT-lock is taken/released it manipulates
On Tue, 2005-04-12 at 15:26, Perez-Gonzalez, Inaky wrote:
> You should not need any of this if your user space mutexes are a
> wrapper over the kernel space ones. The kernel handles everything
> the same and there is no need to take care of any special cases or
> variations [other than the ones
On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
> You basicly need 3 priorities:
> 1) Actual: task->prio
> 2) Base prio with no RT locks taken: task->static_prio
> 3) Base prio with no Fusyn locks taken: task->??
>
> So no, you will not need the same API, at all :-) Fusyn manipulates
>
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>I just wanted to discuss the problem a little more. From all the
>conversations that I've had it seem that everyone is worried about
>having PI in Fusyn, and PI in the RT mutex.
It sure is overlapping functionalities.
> ...
>The RT mutex will
On Tue, 2005-04-12 at 13:33, Joe Korty wrote:
> On Tue, Apr 12, 2005 at 11:15:02AM -0700, Daniel Walker wrote:
>
> > It seems like these two locks are going to interact on a very limited
> > basis. Fusyn will be the user space mutex, and the RT mutex is only in
> > the kernel. You can't lock an
>From: Daniel Walker [mailto:[EMAIL PROTECTED]
>
>> Well yeah, but you could lock a fusyn, then invoke a system call
which
>> locks a kernel semaphore.
>
>Right .. For deadlock detection, I want to assume that the fusyn lock
is
>on the outer level. That way both deadlock detection system will work
>From: Esben Nielsen [mailto:[EMAIL PROTECTED]
>On 12 Apr 2005, Daniel Walker wrote:
>
>>
>>
>> At least, both mutexes will need to use the same API to raise and
lower
>> priorities.
>
>You basicly need 3 priorities:
>1) Actual: task->prio
>2) Base prio with no RT locks taken: task->static_prio
From: Esben Nielsen [mailto:[EMAIL PROTECTED]
On 12 Apr 2005, Daniel Walker wrote:
At least, both mutexes will need to use the same API to raise and
lower
priorities.
You basicly need 3 priorities:
1) Actual: task-prio
2) Base prio with no RT locks taken: task-static_prio
3) Base prio with
From: Daniel Walker [mailto:[EMAIL PROTECTED]
Well yeah, but you could lock a fusyn, then invoke a system call
which
locks a kernel semaphore.
Right .. For deadlock detection, I want to assume that the fusyn lock
is
on the outer level. That way both deadlock detection system will work
properly
On Tue, 2005-04-12 at 13:33, Joe Korty wrote:
On Tue, Apr 12, 2005 at 11:15:02AM -0700, Daniel Walker wrote:
It seems like these two locks are going to interact on a very limited
basis. Fusyn will be the user space mutex, and the RT mutex is only in
the kernel. You can't lock an RT mutex
From: Daniel Walker [mailto:[EMAIL PROTECTED]
I just wanted to discuss the problem a little more. From all the
conversations that I've had it seem that everyone is worried about
having PI in Fusyn, and PI in the RT mutex.
It sure is overlapping functionalities.
...
The RT mutex will never
On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
You basicly need 3 priorities:
1) Actual: task-prio
2) Base prio with no RT locks taken: task-static_prio
3) Base prio with no Fusyn locks taken: task-??
So no, you will not need the same API, at all :-) Fusyn manipulates
task-static_prio
On Tue, 2005-04-12 at 15:26, Perez-Gonzalez, Inaky wrote:
You should not need any of this if your user space mutexes are a
wrapper over the kernel space ones. The kernel handles everything
the same and there is no need to take care of any special cases or
variations [other than the ones
From: Daniel Walker [mailto:[EMAIL PROTECTED]
On Tue, 2005-04-12 at 13:29, Esben Nielsen wrote:
So no, you will not need the same API, at all :-) Fusyn manipulates
task-static_prio and only task-prio when no RT lock is taken. When
the
first RT-lock is taken/released it manipulates task-prio
I think we (at least) got a bit confused here. What (I think) the thread
started out with was a clear layering of the mutexes. I.e. the code obeys
the grammar
VALID_LOCK_CODE = LOCK_FUSYN VALID_LOCK_CODE UNLOCK_FUSYN
| VALID_LOCK_CODE VALID_LOCK_CODE
|
On Tue, Apr 12, 2005 at 11:15:02AM -0700, Daniel Walker wrote:
It seems like these two locks are going to interact on a very limited
basis. Fusyn will be the user space mutex, and the RT mutex is only in
the kernel. You can't lock an RT mutex and hold it, then lock a Fusyn
mutex (anyone
From: Daniel Walker [mailto:[EMAIL PROTECTED]
On Tue, 2005-04-12 at 15:26, Perez-Gonzalez, Inaky wrote:
You should not need any of this if your user space mutexes are a
wrapper over the kernel space ones. The kernel handles everything
the same and there is no need to take care of any special
From: Esben Nielsen [mailto:[EMAIL PROTECTED]
I think we (at least) got a bit confused here. What (I think) the
thread
started out with was a clear layering of the mutexes. I.e. the code
obeys
the grammar
VALID_LOCK_CODE = LOCK_FUSYN VALID_LOCK_CODE UNLOCK_FUSYN
|
On 12 Apr 2005, Daniel Walker wrote:
I just wanted to discuss the problem a little more. From all the
conversations that I've had it seem that everyone is worried about
having PI in Fusyn, and PI in the RT mutex.
It seems like these two locks are going to interact on a very limited
There is a great big snag in my assumptions. It's possible for a process
to hold a fusyn lock, then block on an RT lock. In that situation you
could have a high priority user space process be scheduled then block on
the same fusyn lock but the PI wouldn't be fully transitive , plus there
will be
64 matches
Mail list logo
