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:
>
> http://developer.osdl.org
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 use
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 dif
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 o
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 in
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. I'm
> 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 t
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
> > >
> > /** 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? 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 pro
> 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-sp
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 a
> 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 othe
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 i
> 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 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 prio
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 sep
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 mu
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
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 p
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
> | VA
>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 s
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 di
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
| VAL
>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 im
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->st
>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 neve
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
>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
>3)
32 matches
Mail list logo
